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Chapter  1 


THE  MULTIPLEXED  DATA  BUS  APPROACH  TO  AVIONICS  INTEGRATION 


1.1  Aircraft  Avionics  Integration 

Avionics  integration,  vAiich  is  defined  here  as  the  cooperative  use  of 
shared  informaticn  among  avionic  subsystans,  first  became  a  necessity  vtien 
avionics  hardware  requirements  could  no  longer  be  met  with  independent  and 
self-sufficient  subsystems.  Eliminating  unnecessary  duplication  of 
information  sensing  and  display,  performance  and  reliability  gains,  cost 
reduction,  and  reduction  of  space  requirements  are  usually  given  as  the 
major  reasons  for  integration.  The  avionics  integration  process  typically 
began  with  the  most  ccitplex  subsystem  because  it  had  the  most  capability,  as 
well  as  the  most  need  for  information  fron  other  subsystems.  As  digital 
technology  progressed,  this  central  subsystan  was  expanded  to  incorporate 
mission  processing  (processing  not  specifically  associated  with  a  subsystem 
or  display) . 

Problems  arose  early  in  the  centralization  approach  because  even  though 
the  central  conputer  concept  made  sensible  use  of  shared  information, 
subsystans  were  designed  with  no  concern  for  interconnection  with  other 
subsystens.  Each  subsystem  had  been  specialized,  and  the  interfaces 
reflected  this  specialization.  The  central  corputer  input-output  (l/O) 
circuitry  was  designed  to  perform  the  functions  of  ordering  this  inconing 
and  outgoing  data,  and  the  ccmputer  vas  often  small  coipared  with  the  size 
and  complexity  of  the  l/o. 

It  was  reasoned  that  sane  of  the  centralization  problems  related  to  the 
ccitplexity  of  the  l/O  could  be  solved  if  the  l/O  circuitry  could  by 
partitioned  and  distributed,  alleviating  the  central  unit's  complexity. 
Ccmnercial  data  transfer  trends  supported  this  view.  Multiplexing  makes 
information  transfer  convenient  and  sirtplifies  l/O  because  the  information 
transfer  medium  is  reduced  to  a  single  wire  pair.  Sensors  and  processors 
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are  all  "cn  the  bus."  This  l/O  philosophy  was  adopted  extensively  by 
military  avionics  integrators  and  made  possible  the  distribution  of  the 
computation,  permitting  several  ccrtputers  to  replace  the  more  powerful 
central  processor.  These  multiple  oonputers  added  desirable  redundancy 
features . 

The  integration  approach  using  multiplexing  is  inplemented  by 
specifying  the  following: 

a.  information  transfer  formats 

b.  electrical  interface  characteristics. 

Note  that  functions  are  accomplished  by  both  hardware  and  software . 

Most  of  the  problems  associated  with  centralized  l/O  have  been  eliminated  by 
this  approach,  aM  a  decided  improvement  over  previous  approaches  has  been 
achieved.  The  itodem  integration  approach  uses  multiple  processors  and 
buses  to  functionally  partiticn  the  avionics  along  logical  lines  such  as 
navigation,  stores  management,  and  ccnmunications .  This  functional 
partitioning  eases  the  integraticn  problem  by  allowing  the  subsystons  to  be 
developed  relatively  independently  of  each  other  prior  to  corpleting  the 
total  avionics  integration. 

1.2  Chronology  of  MIL-STD-1553 

Development  of  a  standard  digital  time-division  multiplex  data  bus 
began  in  early  1968  ani  continued  through  1978  with  the  latest  revision 
(MIL-STD-1553B) .  The  Society  of  Automotive  Engineers  (SAE),  Aerospace 
Branch,  established  a  subcoimittee  of  industry  and  military  personnel  in 
1968  to  define  some  of  the  basic  requirements  of  a  serial  data  bus.  By  this 
means,  an  exchange  of  industry  and  military  views  was  accomplished.  The 
ocmnittee  developed  the  first  draft  of  a  data  bus  standard  that  was  similar 
to  the  present  military  standard.  It  represented  a  mixture  of  military 
standard  requirements  and  procuronent  specification  requirements.  Its 
format  allowed  standardization  on  requirements  that  could  be  agreed  upon, 
and  a  slash  ^eet  in  the  ^jpendix  for  requirem^ts  that  appeared  to  be 
vehicle  particular. 
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This  document  represented  the  best  that  the  industry  and  the  military 
could  define  at  the  time.  The  benefit  of  this  document  vas  that  it  produced 
a  sounding  board  for  ideas.  In  this  respect,  it  was  successful  and  provided 
the  step  forward  required  to  develop  the  USAF  military  standard, 
MIL-STD-1553. 

During  the  years  from  inception  of  the  SAE  caimittee  to  the  release  of 
the  first  military  documents,  the  industry  was  designing  and  producing 
hardware  for  various  multiplex  systems.  Seme  of  these  systems  were 
developed  prior  to  or  during  the  standcirdizaticn  era  (e.g.,  F-15  and  B-1). 
Because  of  program  timing,  each  system  went  its  own  vay.  However,  with  the 
production  of  the  F-16,  MIIj-STD-1553(USAF)  found  its  first  full  aircraft 
application . 

By  late  1974  and  early  1975,  the  DOD  directed  the  military  to  develop  a 
single  position  and  to  make  the  necessary  revisions  to  MIL-STD-1553 (USAF) . 
Based  on  this  efforb,  MIL-STD-1553A  was  released  in  i^ril  1975.  Since  1975, 
industry  and  the  military  have  continued  to  coordinate  the  standard  through 
syiiposia,  studies,  and  military  development  programs.  With  the  standard 
available,  the  industry  and  the  military  began  to  apply  the  data  bus  bo  more 
operational  vehicles  and  ^sterns. 

As  applications  became  extensive,  certain  difficulties  were  recognized 
in  MILi-STD-1553A.  Discussions  concerning  these  difficulties  were  conducted 
between  SAE  and  DOD  cormittees,  resulting  in  the  formation  of  an  SAE  task 
groip  in  October  1976  with  the  assignment  to  develop  suggested  changes  to 
1553A.  In  October  1977,  after  review  and  discussion  of  suggested  changes, 
recormendations  were  provided  to  DOD.  MIL-STD-1553B  was  released  as  an 
official  document  on  September  21,  1978. 

1.3  PRACTICAL  COiJSIDERATIONS  OF  SYSTEMS  DflBGRATION 

Improvements  in  mission  capability  provided  by  integration  can  be 
classified  into  four  categories: 
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a.  Performance  gain  by  the  use  of  multiple  subsystons  to  reduce  the 
effect  of  error  sources  vd.thin  a  single  si±isystem;  for  example,  Kalman 
digital  filtering  of  Doppler  and  inertial  navigaticn  subsystem  data  can  be 
used  to  obtain  smoothing  and  prediction. 

b.  Reduction  of  totcil  hardware  by  using  a  single  sensor  to  provide 
conmon  input  data  rather  than  dedicated  input  sensors  for  each  sv±>system. 

c.  Effective  redundancy  without  massive  hardware  duplication  made 
possible  by  the  integration  of  identical,  similar,  or  dissimilar  sensors  to 
make  multiple  sources  of  similar  data  available;  this  is  called  dissimilar 
sensor  redundancy. 

d.  Reduced  weight  and  increased  flexibility  of  integration  and  test 
are  achieved  by  using  multiplexing. 

The  first  three  categories  are  common  to  any  integration  scheme, 
whereas  the  fourth  category  is  associated  with  the  multiplexing  method  of 
achieving  integration.  The  serial,  time-divison  multiplexed  data  bus 
approach  to  avionics  integration  offers  specific  advantages  over  other 
methods. 

Weight  saving  is  achieved  by  the  reduction  of  wire  weight  provided  ty 
the  serial  multiplexing  of  digital  data  as  cottpared  with  the  point-to-point 
interconnection  required  to  achieve  similar  integration  without  the  data 
bus.  The  data  bus  provides  a  path  upon  vhich  many  users  can  cannunicate 
with  each  other  without  requiring  dedicated  links. 

The  flexibility  that  is  available  in  1553  systems  is  one  of  its  most 
important  advantages.  Because  of  the  common  serial  interface,  the  high  data 
rate  (ip  to  50,000  words  per  second),  the  multiple  access,  and  the 
ccttmand/response  data  format,  the  1553  integration  provides  extensive 
flexibility  in  the  development  period  as  well  as  throughout  the  operational 
life  cycle. 
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Another  advantage  of  this  approach  to  informatioi  transfer  is  the 
ability  to  control  data  flow  in  a  scheduled  manner  fron  one  location,  namely 
the  bus  controller.  Changes  in  the  integration  can  be  handled  by  message 
changes  in  the  bus  controller  rather  than  by  wiring  and  hardware  changes  to 
the  subsystems.  Also,  the  benfit  of  a  synchronous  schedule  of  data 
transfers  can  ensure  data  arrival  vhen  it  is  required  and  not  cn  an 
asynchronous,  uncontrolled  basis. 

Finally,  the  concept  of  multimission  roles  for  a  single  airframe  {or  a 
restricted  family  of  airframes)  has  beccme  a  major  element  in  our  military 
weapon  planning.  Changing  threats  m^e  it  necessary  to  plan  for 
mission-adaptive  and  threat-adaptive  avionics  systems  over  the  life  of  an 
airframe.  In  the  past  few  years,  it  has  been  a  goal  of  the  DOD  to  develop 
and  apply  methods  and  technologies  that  would  permit  avionic  systems  to  be 
developed  vhich  are  easily  constructed,  modified,  and  operationally  verified 
as  missioi  needs  change. 

TWO  multimission  concepts  have  anerged.  One  approach  is  to  design  a 
core  set  of  avionics  and  peripheral  avionics  so  the  avionic  suite  can  be 
readily  changed  by  removing  and  replacing  mission-dependent  functions 
(peripheral  avionics) .  Another  approach  is  to  depend  cn  established 
interface  standards  (e.g.,  standard  hardware  and  software  modules)  that 
permit  an  avionics  system  to  be  i:pdated  (retrofitted)  throughout  the  life  of 
the  airframe.  Both  of  these  approaches  represent  ideal  applications  of 
multiplexing  for  integration. 


This  Page  Intentionally  Left  Blank 
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Chapter  2 


OVERVIEW  OF  MIL-STD-1553 


The  purpose  of  this  chapter  is  to  present  the  organization,  scope,  and 
contents  of  MIL-STD-1553  to  assist  readers  vho  are  unfamiliar  it.  The 
current  versicn  of  1553  (namely  1553B)  vdll  be  discussed  and  key  terms 
explained . 

2.1  Scope  of  the  Standard 

A  military  standard  is  a  document  that  establishes  engineering  and 
technical  requirements  for  processes,  procedures,  practices,  and  methods. 
MIL-STD-1553,  "Aircraft  Internal  Time  Division  Gamnand/Response  Multiplex 
Data  Bus,"  has  been  widely  used  in  integrated  avionics  designs  since  1973. 
Each  word  in  the  title  of  the  standard  has  a  specific  meaning: 

a.  Aircraft.  This  word  denotes  that  the  data  buses  are  installed  in 
DOD  aircraft.  Although  there  are  instances  of  1553  data  buses  used  in 
ground  applications,  the  characteristics  of  the  bus  have  been  determined 
by  aircraft  requirements. 

b.  Internal.  This  word  denotes  that  the  data  bus  is  used  for 
transmission  only  within  an  aircraft. 

c.  Time-Division  Multiplex.  The  type  of  multiplexing  for  which  the 
standard  establishes  requirements.  Time-division  multiplexing  is  the 
transmission  of  information  form  several  signal  sources  through  cne 
ccrnnunication  system  with  different  signal  saitples  staggered  in  time  to 
form  a  ccmposite  pulse  train.  A  transmission  line  known  as  a 
twisted-shielded  wire  pair  is  used  for  transmission;  consequently,  all 
messages  must  be  transmitted  and  received  serially.  The  1553  data  bus 

is  scmetimes  referred  to  as  the  1553  serial  data  bus. 

d.  Cctnnand/Response.  This  denotes  the  ccnmunication  protocol  that 
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distinguishes  1553  data  bus  operation  from  that  of  other  data  buses. 
Basically,  the  ccnmand/ response  protocol  described  in  1553  is  a  "speak  only 
vhen  spoken  to"  oanmunication  that  is  solely  the  responsibility  of  a 
designated  controller. 

2.2  Information  Transfer  Formats 

The  term  "information  transfer  formats"  is  used  in  1553B 
interchangeably  with  "message  formats."  The  exchange  of  messages  in  1553B 
is  very  precisely  described,  with  10  allowable  formats  (see  fig.  2-1).  If 
an  exchange  cannot  be  conpleted  because  of  hardware  or  software  failures, 
the  standard  specifies  vhat  is  to  be  done.  All  methods  of  followup  to  retry 
the  message  or  to  determine  the  failure  must  be  done  within  the  allowable  10 
message  formats.  It  is  this  idea  of  proper  exchange  of  messages  that  makes 
it  appropriate  to  refer  to  them  as  "protocol"  —  because  it  is  similar  to 
the  process  that  diplcmats  use  to  exchange  state  notes.  Message  formats  are 
cctt^sed  of  words,  response  time  gaps,  and  intermessage  time  gaps. 

Message  formats  are  divided  into  two  groups:  mode  cotmands  and  data 
transfers . 

2.2.1  Mode  Ccnmands 


Mode  comiands  are  those  formats  reserved  for  oomunication  with  the  bus 
hardware  and  informatiai  flow  management. 

There  is  provision  for  32  lonique  mode  ccranands,  and  1553B  specifies  the 
base  2  numbers  that  cire  to  be  used  for  15  of  these.  The  balance  are 
reserved,  vhich  means  the  designer  must  secure  special  approval  to  use  a 
reserved  mode  ccrittiand  number.  Ebwever,  the  use  of  any  or  all  defined  mode 
cannands  is  optional. 

2.2.2  Data  Transfers 


Data  transfer  message  formats,  cn  the  other  hand,  do  not  restrict  the 
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Figure  2-1.  Information  Transfer  Formats 


Figure  2-1  (cont'd) .  Information  Transfer  Formats 


designer  to  the  same  degree  as  mode  cotitiands.  The  restrictions  are  (1)  no 
more  than  32  words  in  any  single  message  are  to  be  used  and  (2)  the  most 
significant  bits  of  any  value  or  quantity  will  be  transmitted  first,  with 
bits  of  descending  significance  following. 

2.3  MIL-STD-1553  Terminals 

A  terminal  is  "the  electronic  module  necessary  to  interface  the  data 
bus  with  the  si±)system  and  the  subsystem  with  the  data  bus ..."  There  are 
only  three  functional  modes  of  terminals:  the  bus  controller,  the  bus 
monitor,  and  the  remote  terminal.  The  definition  of  a  terminal  as  an 
electronic  module  ^ould  ocnvey  the  notion  of  a  piece  of  hardware  that 
contains  digital  logic.  Significant  digital  corplexity  is  required  because 
of  1553  response  time  and  data  storage  specifications. 

2.3.1  Bus  Ctontroller 


The  definitions  section  states  that  the  bus  controller  is  "the  terminal 
assigned  the  task  of  initiating  information  transfers  cn  the  data  bus." 

Other  requirements  are:  (1)  "The  bus  controller  is  the  key  part  of  the  data 
bus  system,"  and  (2)  "Sole  control  of  information  transmission  on  the  bus 
shall  reside  with  the  bus  controller ...  . "  These  quotes  clearly  define  the 
bus  controller. 

2.3.2  Bias  Monitor 


The  standard  defines  the  bus  monitor  as  "the  terminal  assigned  the  task 
of  receiving  bus  traffic  and  extracting  selected  information  to  be  used  at  a 
later  time."  Bus  monitors  are  frequently  used  for  instrumentation. 

2.3.3  Remote  Terminal 


Any  terminal  that  is  not  operating  in  either  bus  controller  or  bus 
monitor  mode  is  operating  in  the  remote  terminal  mode. 
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2.4  Types  of  1553  Vfords 


There  are  cnly  three  types  of  words:  ccranand  vords,  status  vords,  and 
data  words.  In  1553,  a  word  is  "a  sequence  of  16  bits  plus  sync  and 
parity."  The  role  of  each  of  the  three  allowable  vrord  formats  is  as 
follows : 


a.  Ccnmand  Vford.  This  vrord  is  always  used  as  the  first  word  (or 
words)  of  a  message.  It  will  only  be  transmitted  ty  a  bus  controller.  This 
word  defines  the  type  of  information  transfer  format  that  will  be  used. 

b.  Status  Word.  This  word  is  always  used  as  the  first  word  that  is 
transmitted  by  a  remote  terminal.  (Bus  monitors  do  not  transmit  at  all.) 
This  word  contains  the  status  of  the  transmitting  remote  terminal. 

c.  Data  Vibrd.  This  wcrd  (or  words)  is  always  transmitted 
contiguously  w/ith  a  ccnmand  word,  status  word,  and  other  data  words. 
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Chapter  3 


MULTIPLEX  SYSTEM  EESIGN 

3.1  AVIC4JIC  INIEGRATIOJ  DESIGN  ACTIVITIES 

System  design  begins  vdth  the  statement  of  the  requirements  for  avionic 
functions.  The  overall  hardware  and  software  requirements  for  a  multiplex 
system  will  be  derived  fran  examination  of  functions  and  data  requirements 
in  the  following  cureas: 

a.  Subsystems  connected  to  the  multiplex  bus  (or  buses) . 

What  is  connected  to  the  bus?  What  are  the  data  paths  in  the 
avionic  system  using  the  buses?  What  redundancy  of  data  paths 
has  been  provided?  What  redundancy  and/or  isolation  of  function 
and  equipment  is  required?  Answers  to  these  questions  provide 
the  overall  context  of  avionics  systan  operation. 

b.  Missions  and  modes  of  each  mission.  It  is  necessary  to 
know  the  ccmplete  repertoire  of  missions,  how  these  missions  are 
supported  1:^  functions  of  the  avionic  systems,  and  vhat 
p)articular  functions  are  to  be  performed  during  each  phase  of  the 
mission.  These  groupings  of  functions  bfy  flight  jhase  are  called 
modes.  (Note  that  these  systen  or  sensor  modes  are  not  related  to 
MIL-STD-1553  "mcde  codes.")  For  exanple,  the  weapxDn  delivery 
mode  is  usually  distinguished  fron  the  waypoint  navigation  mode, 
even  though  navigation  sensors  may  be  i:ised  in  each. 

c.  Functions  of  each  sensor.  Descriptions  are  needed  for 
the  inputs  that  each  sensor  requires  (including  sensor  control 
information),  vAiat  processing  (contputation)  of  sensor  data  is 
required  for  all  avionic  functions,  and  vhat  data  the  sensor 
provides  to  other  avionic  systems.  The  sensor  redundancy 
concepts  and  how  data  frcm  redundant  sensors  will  be  used  or 
reconciled  need  to  be  described,  as  well  as  sensor  modes  versus 


13 


vdiicle  (avionic,  weapon,  flight  control)  modes.  Thorough 
descripticn  of  the  interrelationship  of  sensors  is  required 
(e.g.,  inertial  navigation  tpdate  using  another  position-fixing 
sensor) . 


d.  Functions  of  control  and  display.  Descriptions  are 
required  for  the  overall  interface  of  the  controls  and  displays 
to  the  avionic  systems,  as  well  as  vhich  control  and  display 
functions  depend  on  multiplexed  data. 

e.  Other  avionic  functions.  The  advantages  of 
multiplexing  often  are  applied  not  only  to  the  integraticxi  of 
sensors,  processors,  and  controls  and  displays  but  also  to  more 
siiiple  devices  like  switch  positions,  actuator  positions,  and 
power  control .  It  is  because  of  this  application  flexibility 
that  the  overall  use  of  data  in  the  syston  must  be  described. 

The  requirements  derived  frcm  these  considerations  will  establish  the 
overall  use  of  the  1553  data  bus.  It  is  quite  likely  that  additional 
dedicated  discretes  will  be  used  in  an  integrated  system  for  critical 
functions  (e.g.,  stores  managonent  enable  or  jettison).  These  interfaces 
need  to  be  established  and  described  at  the  same  time  the  multiplex 
description  is  developed. 

3.1.1  Functional  Partitioning 

The  redundancy  provided  ty  the  multiplex  system  is  one  of  the  key 
concerns  and  design  requirenents  facing  the  system  designer.  The  system 
designer  must  consider  the  following: 

a.  The  basic  level  of  redundancy  within  each  subsystem. 

b.  The  highest  mission  success  probability  associated  with  every 
functicai  of  each  subsystem. 

c.  The  isolation  of  each  sv±)system  from  other  subsystems. 


14 


d.  The  independence  of  the  redundant  elements  within  each 

subsystem. 

Based  cn  this  information  about  each  sxibsystem  being  served  and  any 
added  vehicle  particular  requirements  (e.g.,  battle  damage,  no  single 
failure  can  cause  . . .  etc . ) ,  the  syston  designer  is  able  to  establish  a  set 
of  multiplex  systan  requirements.  These  requirements  will  impact  topology, 
multiplex  control,  and  avionic  control.  The  topology  is  usually  the  most 
visible  point  in  the  multiplex  system  vhere  redundancy  can  be  observed. 
However,  the  system  designer  must  consider  much  more  than  just  having  a 
topology  that  meets  the  observable  redundancy  requirements.  The  redundancy 
of  the  bus  controller  and  its  associated  circuitry  involved  in  the  detection 
and  correction  of  a  failinre  as  well  as  the  same  functions  in  a  remote 
terminal  are  all  part  of  meeting  the  redundancy  requirements  of  the 
integration. 


3.1.2  Data  Bus  Topology 

Data  bus  topology  is  the  map  of  physical  connections  of  the  data  bus 
termineils  to  the  data  bus.  It  includes  all  terminals  and  data  buses 
involved  in  the  data  bus  integration  of  the  vehicle.  Data  bus  topologies 
can  be  categorized  into  the  following  two  general  categories: 

a.  Single  level 

b.  Multiple  level 

A  single  level  bus  topology  is  the  sirt^jlest  bus  topology  and  is 
exemplified  by  the  F-16  avionic  bus  architecture  (see  fig.  3-1).  In  a 
single-level  bus  topology,  all  terminals  are  interconnected  via  the  same 
data  bus.  The  redundancy  requirements  of  a  particular  application  may 
require  a  single-level  topology  to  be  iitplemaited  using  multiple 
interconnecting  cables  operating  in  various  inodes  (active  or  passive) . 
However,  the  requirements  to  use  multiple  buses  for  redundancy  purposes  does 
not  change  the  single-level  bus  topology  definition  if  the  following 
criteria  are  maintained: 
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a.  All  termineils  are  connec±ed  to  each  data  bus  cable 

b.  Gcmnunication  on  each  data  bus  is  identical 

The  methods  of  bus  control  and  the  redundancy  connunication  techniques 
used  are  peculiar  to  the  application  and  will  be  discussed  under  these 
areas. 

Hie  multiple-level  bus  topology  is  an  expansion  of  the  single-level 
topology  and  can  be  expressed  in  two  basic  forms: 

a.  Multiple  levels  of  buses  with  equivalent  levels  of  control 

b.  Multiple  levels  of  buses  with  hierarchical  levels  of  control 

The  multiple-level  bus  topology  with  equivalent  levels  of  control  is 
exearplified  by  weapcai  systems  that  use  multiple,  single-level  bus  topologies 
for  different  functions.  An  exaitple  of  this  relationship  are  the  B^l  EMUX, 
AMUX,  and  CITS  (see  fig.  3-2),  that  represents  three  single-level  bus 
topologies  with  interconnections  for  data  exchange  purposes  only,  thus 
producing  a  multiple-level  bus  topology  for  the  vehicle.  Eacdi  of  these 
single-level  bias  topologies  operates  independently  of  the  others  with 
equivalent  levels  of  control.  Another  method  of  achieving  a  multiple-level 
bus  topology  within  a  subsystem  integration  is  exeitplified  ty  the  B-52  QAS 
(see  fig.  3-3)  multiple-level  bus  topology,  vhich  is  partitioned  into  two 
single-level  topologies  (i.e.,  ocntrol  and  display  versus  navigation  and 
weapon  delivery).  This  trend  to  multiple,  single-level  topologies  within  a 
vehicle  or  in  a  large  si±>system  integration  is  a  natural  evolution  of  the 
single-level  bus  topology. 

A  second  form  of  multiple-level  bus  trilogies  occurs  vhen  one  or  more 
single-level  bus  topologies  are  integrated  with  another  single-level  bus 
topology  vhere  the  levels  have  a  control  relationship  (see  fig.  3-4).  The 
bus  level  inequality  may  be  expressed  as  follows: 

a.  local  buses,  si±ordinate  (under  si±iTiission  to  global  bus) 

b.  Global  bus,  superior  (control  over  local  buses) 
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Figvire  3-4.  Hierarchical  Multiplex  Architecture 


The  primary  reason  for  the  difference  in  control  is  based  on  functional 
usage  and  not  cn  the  interconnection  of  the  terminals.  Data  bus  topologies 
can  also  be  defined  on  the  basis  of  interconnection  requirements  of  the  user 
terminals.  These  requirements  would  also  establii^  the  interconnection  of  a 
sensor  to  a  local  or  a  global  bus. 

3.2  Data  Bus  Control 

The  oontrol  philosophy  used  to  maintain  the  ocrmunication  on  a  data  bus 
is  described  MIL-STD-1553.  The  control  approaches  are  of  two  types: 

a .  Stationary  master 

b.  Nonstationary  iraster 

The  stationary  master  bus  oontrol  concept  is  used  vhen  a  single  bus 
controller  orchestrates  the  bus  camtunication  for  all  devices  on  that  data 
path.  Only  in  the  event  of  a  feilure  of  the  bus  controller  hardware  or 
software  will  another  bus  controller  (backup  bus  controller)  operate  the 
data  bus.  Obviously,  as  discussed  in  the  topology  section,  multiple 
stationary  master  bus  controllers  can  exist  within  a  system,  each 
controlling  its  cwn  data  bus. 

The  nonstationary  naster  bus  control  concept  is  used  vhen  more  than  one 
bus  controller  orchestrates  the  bus  catinunicabcxi  for  devices  on  that  data 
path.  MIL-STE>-1553B  provides  a  method  of  transferring  oontrol  frcm  an 
active  bus  controller  to  a  potential  bus  controller  (dynamic  bus  control 
mode  code) .  This  mode  code  provides  a  protocol  format  for  issuing  the  bus 
controller  offer  with  the  responding  status  word  providing  an  acceptance  or 
rejection  of  the  offer.  Since  the  military  standard  prevents  the  operation 
of  multiple  bus  controllers  simultaneously,  a  method  must  be  established  to 
determine  vhen  the  above  mode  code  is  to  be  issued  and  "to  vhom"  it  should 
be  offered.  The  development  of  the  timing  (vhen)  and  the  ordering  (hew  the 
selection  is  achieved)  is  not  specified  by  the  standard  and  must  be 
established  by  the  system  design. 
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3.3 


SOPIWARE  DESIGN 


This  section  deals  vdth  the  techniques  and  considerations  of  software 
design  for  an  avionic  system  using  1553  data  buses.  The  discussion  is 
concerned  with  the  software  that  controls  messages  on  the  bus  rather  than 
application  software.  The  term  "control  software"  includes  the  avionic 
system  executive,  bus  control,  and  error  handling.  The  term  "application 
software"  includes  such  functions  as  navigation  (dead  reckoning,  aided 
inertial  dead  reckoning,  navigation  sensor  management)  fire  control,  weapon 
delivery,  and  cannunication  control.  The  interface  of  application  functions 
with  system  control  is  included  and  is  discussed  frcm  the  point  of  view  of 
segregating  all  supervisory  functions  frcm  application  software.  Obviously, 
the  multiplex  system  software  must  support  the  performance  of  all  required 
avionic  systan  functions. 


3.3.1  S!i!STEM  COSITROL  GCaJSIDERATIC»JS 


The  software  designer  of  a  multiplex  system  is  typically  faced  with  the 
task  of  determining  the  total  software  requirements  concurrently  with  system 
and  hardware  design.  The  software  engineer  must  obtain  the  requirements  for 
software  (of  which  the  system  control  will  be  least  obvious)  frcm  several 
sources.  "System  control"  means  both  multiplex  system  and  avionic  system 
nonitoring  for  correct  operation,  error  handling,  and  failure  handling. 

The  1553  standaird  requires  the  bus  controller  to  initiate  eill  data  bus 
transfers.  The  question  of  "vho  is  in  control"  is  very  inportant.  Since 
the  bus  controller  operation  is  the  single  point  of  avionic  and  multiplex 
system  control,  it  diould  meet  the  redundancy  requirements  of  the  entire 
system.  Answers  to  the  following  questions  relating  to  the  approach  for  bus 
control  are  essential:  (1)  What  is  the  overall  approach  to  controlling  the 
data  transfers  of  the  avionics  system?  (2)  What  is  the  concept  of 
redundancy  with  respect  to  the  bus  control?  Is  it  a  duplicate  capability, 
an  alternative  control  capability,  or  an  alternative  controller  managing 
limited,  degraded,  or  backup  capability? 
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The  requirements  of  avionic  system  control  cannot  be  defined  without 
clear  definition  of  the  weapon  system  functions,  the  sensors,  the  avionic 
architectures,  and  the  functions  allocated  to  or  expected  of  software.  Ihe 
following  sections  discuss  control  considerations  from  three  interrelated 
points  of  view:  data  transfer  control,  multiplex  system  control,  and  errors 
and  hardware  failures. 

3. 3. 1.1  Data  Transfer  Description 

It  is  necessary  to  define  all  avionic  system  data  transfers  that  are 
implonented  using  the  multiplex  bus.  An  examination  of  these  will  establish 
control  requirements.  Each  individual  data  transfer  must  be  defined  in 
terms  of  the  following  attributes  for  each  mode: 

a.  Source  function 

b.  Destination  function 

c.  Data  definition  in  16-bit  words 

d.  Iteration  rate  if  it  is  periodic  data 

e.  Conditional  events  if  it  is  aperiodic  data 

f.  Allowable  latency 

g.  Conditional  events  related  to  the  data  paths 

h.  Error  response  characteristics 

Determining  the  source  and  destination  of  each  data  item  is  the  first 
step  in  the  definition  of  the  input  and  output  of  the  functioning  avionic 
system.  Included  in  this  description  is  the  definition  of  the  data  in  terms 
of  16-bit  words  because  that  is  the  medium  of  transmissicn  over  the  bus.  A 
data  item  may  be  an  input  to  different  functions  according  to  the  particular 
phase  of  the  mission  and  may  be  transmitted  at  different  frequencies. 

Most  multiplexed  avionic  systems  operate  on  fixed  schedules  of  data 
transfers.  The  requirements  for  the  scheduling  cane  frcm  the  examination  of 
the  largest  and  smallest  minimum  iterations  and  allowable  latencies.  The 
slowest  iteration  rate,  vdiich  is  the  least  comnon  multiple  of  the  faster 
iteration  rates,  is  normally  defined  as  the  major  cycle  (see  fig.  3-5). 

Over  the  course  of  a  major  cycle,  all  periodic  transmissions  and  all 
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Figure  3-1.  Major  Cycle 


periodic  ccmputations  occur  at  least  once.  The  minor  cycle  is  normally  the 
frequency  of  the  most  rapidly  transmitted  periodic  data.  Typical  major 
frames  are  1  second  in  length,  vhile  minor  frame  lengths  can  be  binary 
(2^/sec)  or  decimal  (10^/sec)  vdth  ocrntnon  values  being  1/128,  l/64,  1/50 
sec,  etc. 

6. 

For  exanple,  if  the  major  frame  is  1  sec  long  and  there  are  64  (2  ) 
minor  cycles,  then  each  minor  cycle  is  1/64  seconds  or  15.625  ms  long.  Each 
periodic  message  would  occur  at  least  once  each  major  frame,  i^)  to  a  maximum 
of  64  times.  If  a  transaction  needed  to  occur  eight  times  per  second,  it 
must  cxrcur  during  one  of  the  first  eight  minor  cycles  (64/8  =  8)  and  every 
eight  minor  cycles  thereafter. 

In  the  exaitple  of  a  transaction  occurring  eight  times  per  second,  shown 
in  Table  3-1,  if  the  first  transaction  occurred  in  minor  cycle  3,  later 
transactions  would  occur  in  minor  cycles  11  (i.e.,  8  +  3),  19,  27,  35,  43, 
55,  and  63. 

/^riodic  messages,  vhile  rare,  are  based  i^cai  conditional  events,  such 
as  a  requirement  to  presont  a  display  to  a  crewnember  within  X-milliseconds 
of  keyed-in  octtinands,  or  a  requirement  to  acquire  data  in  a  data  buffer 
before  it  is  lost  to  the  next  input  to  the  buffer.  The  latter  case  is 
typical  for  keystrokes  from  keyboards. 

24 


3. 3. 1.2  Multiplex  Syston  Control 


MIL-STD-1553  requires  that  the  multiplexed  data  transfers  be  initiated 
by  a  bus  controller  and  be  followed  by  a  response  frcm  a  terminal  in  normal 
operation.  The  only  exception  is  that  a  bus  controller  may  ccmnand  a 
broadcast,  v^icih  does  not  require  a  response.  In  all  cases,  the  actual 
transmission  is  either  a  ccrribination  of  protocol  data  and  avionic  data 
formatted  into  16-bit  words  or  it  is  a  transmissicn  of  protocol  information 
without  avionic  data. 

The  types  of  data  transfers  and  the  implications  for  the  software 
designer  are  as  follows: 

a.  Remote  terminal  to  bus  controller.  This  type  of  data 
transfer  is  used  to  provide  data  to  the  bus  controller.  The  bus 
controller  is  almost  always  a  mission  conputer,  fire  control 
cotputer,  navigation  cotputer,  etc.  It  requires  data  frcm 
several  sources,  such  as  an  air  data  sensor,  inertial  measurement 
unit,  radio  navigation  sensor,  etc.,  to  perform  its  assigned 
cdiputational  functions.  Therefore,  it  usually  will  also  be 
assigned  the  fmction  of  bus  controller  and  will  initiate  the 
requests  to  the  remote  terminals  for  the  data  that  it  needs.  The 
data  needs  of  the  mission  ocnputer  establish  the  requirements  for 
data  transfers  to  it  frcm  other  sources  on  the  bus. 

b.  Bus  controller  to  remote  terminal.  Typically  these  types  of 
data  transfers  are  related  to  the  role  of  the  processor  that  has 
the  bus  control  function.  A  mission  ocnputer  may  have  the 
requiranent  to  be  the  data  source  to  devices,  providing  such  data 
as  position  update  to  an  INS,  or  the  requirement  to  transmit 
display  parameters  to  a  graphics  generator.  The  mission  conputer 
often  serves  as  the  processor  to  effect  veapon  system  ccaitrol, 
such  as  fire  control,  in  vhich  case  it  is  controlling  both  the 
multiplex  system  and  computing  parameters  for  target  designation, 
weapon  initialization,  etc.  In  this  case,  controller  to  remote 
terminal  transfers  are  data  transfers  frcm  the  fire  control 
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coiputer  to  the  remote  terminals  that  cxontain  the  interfaces  to 
target  designators,  stores,  etc.  These  types  of  data  transfers 
may  also  be  used  as  a  method  of  central  distribution  in  vhich 
data  are  taken  from  a  remote  terminal,  reformatted  and 
retransmitted  to  other  locations. 

c.  Remote  terminal  to  remote  terminal.  The  bus  controller  does 
not  need  to  receive  and  retransmit  all  data  even  though  it  is  in 
control  of  the  bus.  An  irrportant  class  of  data  transfers  is  the 
direct  transfer  of  data  frcm  one  remote  terminal  to  another, 
vhich  can  be  used  if  the  processor  that  contains  the  bus 
controller  is  not  involved  in  the  processing  of  the  data  and  if 
reformatting  is  not  required.  In  avionic  systems  that  enploy 
more  distributed  processing  (e.g.,  CADC,  INS  on  the  bus)  the 
additional  processing  capability  at  those  remote  terminals  can  be 
used  to  select  and  format  data  for  direct  remote-terminal-to- 
remote-terminal  data  transfers. 

d.  Broadcast.  Ihe  broadcast  data  transfer  is  an  option  of  1553B 
but  not  currently  in  general  use  in  military  avionics.  Broadcast 
allows  the  simultaneous  transmission  of  the  same  data  to  more 
than  one  remote  terminal.  This  transfer  format  may  be  used  for 
avionic  data  transfers  vhen  significant  reduction  in  processing 
or  bus  message  traffic  is  needed  and  the  ccnmand/response 
validation  feature  of  each  message  is  not  required.  For  exanple, 
broadcast  of  roll  and  pitch  data  for  aircraft  flight-path  control 
to  a  dual-,  triple-,  or  quad-redundant  flight  control  system  may 
serve  to  sinpliJ^  both  avionics  and  flight  control  software. 

Note  that  broadcast  does  not  eliminate  the  need  to  determine 
status  (e.g.,  message  received)  but  that  status  must  be 
determined  by  separate  requests  of  the  controller  to  remote 
terminals. 

Each  unique  data  transfer  must  ultimately  be  identified  to  the 
multiplex  system  hardware  and  software  by  its  unique  cctiibination  of  terminal 
address  and  subaddress.  It  is  this  feature  that  establishes  the  requirement 
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that  the  data  transfers  be  organized  into  messages.  It  is  camon  in  the 
system  design  process  to  prepare  tables  that  define,  for  each  stbsystem  on 
the  bias,  the  ocmplete  data  transfer  specification  into  messages.  Bitries  in 
the  table  are  usually  as  follows: 

a.  Subsystem  name,  for  exartple,  INU,  CADC,  radar. 

b.  Subsystem  terminal  address. 

c.  Data  block  ID. 

d .  Subaddress . 

e.  Vtord  count. 

f .  Refresh  rate,  for  exaitple,  the  rate  at  vhich  the  si±)system  updates 

a  variable. 

g.  Transmit  rate,  usually  stated  as  a  minimum  value,  at  vhich  the 

subsystQoi  will  be  requested  to  transmit  the  data. 

Separate  tables  are  required  for  transmit  and  for  receive  for  each 
terminal,  vAiether  it  is  a  remote  terminal  or  a  bus  controller.  The  software 
designer  must  define  all  data  blocks  that  will  be  transmitted  or  received 
under  all  system  conditions,  normal  or  abnormal.  The  control  software  will 
handle  the  data  according  to  the  data  block  definition.  Therefore,  an  exact 
correspondence  between  the  input  and  output  of  data  blocks  and  the  use  of 
the  data  must  exist. 

Multiplex  system  control  and  avionic  system  control  are  accorplished 
in  software  via  the  executive.  The  executive  manages  the  multiplex  elements 
in  both  normal  and  error  conditions.  Ncrmal  operating  ccnditions  include: 

a.  Initialization  of  the  bus. 

b.  Effecting  the  transmission  of  messages. 
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c.  Setting  up  of  proper  output  message  sequences. 

d.  Timirg  for  periodic  message  sequences. 

e.  i^riodic  message  setup,  transmission,  and/or  reception. 

f.  Coimunication  of  time  event  or  message  event  (arrival)  to  an 
application  task  controller  or  to  the  recipient  task. 

g.  Transfer  of  control. 

h.  Reconfiguration  due  to  change  of  mission  mcde. 
i^normal  operating  conditions  incliade: 

a.  Handling  transmissions  eiarors. 

b.  Responses  to  failure  of  subsystems  on  the  bus. 

c .  Failure  record-keeping . 

d.  Reconfiguraticn  because  of  failure. 

3. 3. 1.3  Errors  and  Hardware  Failures 

Provision  must  be  made  during  system  design  to  handle  errors  in  data 
transmission,  power  transients,  hardware  failures,  and  data  errors. 
Determining  the  requirement  for  a  response  to  a  detected  error  is  difficult, 
because  there  is  no  guidance  in  1553  and  no  well-accepted  guidelines  for 
doing  an  analysis  that  shows  that  one  set  of  responses  is  superior  to 
another  if  missioi  success  probability  is  the  measure.  If  mission  success 
probability  is  ccmputed  for  several  candidate  responses  to  detected  errors, 
only  those  actions  that  increase  the  probability  should  be  considered  for 
inplementation.  laboratory  investigation  (such  as  in  a  hot  bench)  may  be 
highly  desirable  to  determine  both  the  effect  of  a  response  and  the  cost  in 
software  to  get  the  response. 
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The  1553  data  bus  does  provide  superior  error  detection  capability  for 
messages  intended  to  be  transmitted  and  received.  This  does  not  mean  that 
inherent  errors  in  data  are  also  detected.  Therefore,  a  software  engineer 
should  include  data  reasonableness  checks  or  other  authentication  before 
data  are  xased.  This  is  particularly  inportant  for  any  data  that  are 
critical  to  mission  success. 
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Chapter  4 


EVOLUTION  TCWMRD  A  MULTI-BUS  ARCHITECTURE 
FOR  AR^  HELICOPTER  AVIONIC  SYSTEMS 


Over  the  past  decade  the  architecture  of  Am:^  helicopter  avionic 
systans  has  evolved  from  stand-alone  sxabsystans  to  integrated  subsystems 
characterized  by  digital  data  buses  and  embedded  microprocessors.  As  these 
first  generaticn  integrated  systors  are  reaching  maturity,  the  U.S.  Amy 
Avionics  laboratory  is  turning  its  attention  to  seme  of  the  issues  vAiich 
must  be  addressed  in  preparation  for  the  development  of  future  systems. 

This  paper  presents  an  evolving  concept  for  a  data  bus  and  processing 
structure  vhich  is  being  developed  under  an  in-house  Avicaiics  Laboratory 
technology  base  effort. 

4.1  Avionics  Architecture  Requirements 

As  a  result  of  the  need  for  significantly  increased  integration  of 
aircrew  functions  to  meet  the  demands  being  placed  on  Arrty  Aviation,  it  has 
beceme  apparent  that  a  technical  requirement  exists  for  an  architectural 
concept  with  a  nuitiber  of  characteristics  that  go  beyond  that  v>hicih  is  in 
development  today.  Per  exairple,  many  of  the  subsystems  that  come  together 
to  synthesize  a  total  helicopter  avionic  systan  are  developed  by 
organizations  with  specific  expertise  in  various  functional  areas  (e.g., 
navigation,  flight  control,  weapons,  target  acquisition,  etc.).  These 
organizations  are  usually  both  geographically  and  raanagerially  separated, 
both  in  the  government  (custemer)  and  in  private  industry  (supplier).  It 
has  became  apparent  that  an  architectural  concept  is  required  that  will 
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allow  these  various  func±.ional  areas  to  develop  both  subsystem  hardware  and 
software  independently  and  still  cxsnforni  to  an  architecture  that  facilitates 
future  total  system  integration.  Similarly,  subsystem  requirements  in  the 
control/display  area  must  be  developed  with  the  subsystem.  However,  the 
architectural  concept  must  allcw  subsyston  control/ display  functions  to  be 
mapped  into  the  total  helicopter  control/display  system  without  re-doing  the 
associated  software.  Frcm  the  subsystem  developer  viewpoint,  the  system 
architecture  must  be  such  that  at  the  time  of  total  system  integration, 
subsystem  specific  hardware  (e.g.,  sensors)  must  be  easily  incorporated  into 
the  bus  structure  and  the  system  level  software  absorbable  into  the  system 
processing  elotients. 

Another  desirable  feature  or  characteristic  of  the  new  architecture 
would  be  a  means  for  high  speed  interface  between  processing  elements  of  the 
system.  Additionally,  both  the  processing  structiare  and  bus  structure  must 
lend  itself  to  fault  tolerant  designs. 

Finally,  there  are  two  remaining  areas  vAiich  the  architectural  concept 
must  address  if  it  is  to  be  widely  accepted.  First,  the  hardware 
inplementation  of  the  concept  must  be  such  that  it  lends  itself  to  a 
procurement  process  that  does  not  unnecessarily  restrict  the  government  and 
contractors  to  either  each  other  or  specific  technology;  and  second,  the 
processing  elements  must  be  such  that  standardizaticxi  can  be  achieved  cffi  a 
foundation  of  structured  progranming  and  a  higher  order  language. 

Considering  all  of  the  above  characteristics,  an  architectural  concept 
is  evolving  based  oi  multi-buses  and  multi-processors. 


4.2  Evolution  To  Date 

It  is  most  helpful  prior  to  presenting  a  proposed  architecture  to  first 
look  back  and  review  the  thought  processes  that  led  to  our  current 
architecture . 
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An  accepted  beginning  to  this  era  of  integrated  system  architectures  is 
the  prcmulgation  and  acceptance  of  the  U.S.  MILi-STD-1553  data  bus  (NATO 
STANAG  3838) .  For  ease  of  discussion,  let  the  line  depicted  in  Figure  1 
represent  such  a  dual  (redundant)  tvd.sted  diielded  pair  data  bus.  The  Am^ 
Avionics  Laboratory  first  used  the  bus  concept  to  integrate  the  aircraft 
cannunication,  navigation,  and  identification  (CNI)  equipment  (see 
referenced  paper) .  Architecturally  speaking,  the  integration  of  this 
equipment  can  be  represented  ty  Figure  2.  In  general,  all  processing  was 
acccnplished  in  8-bit  microprocessors  oiibedded  in  Remote  Terminals  (RT's) 
vhich  also  served  as  interface  media  to  the  itostly  existing  inventory  radio 
equipments.  One  or  more  control/display  units  (QDU's)  provided  means  for 
crew  interface.  Architecturally,  the  ^stem  can  be  characterized  as  of  lew 
bus  data  rate,  modest  level  of  fault  tolerance  (e.g.,  completely  redimdant 
processing) ,  and  little  synergism.  The  software  was  in  assembly  code  and 
generally  not  portable.  Spinoffs  of  this  system  developed  by  the  Anry  are 
currently  being  used  in  a  large  variety  of  ciircraft  (such  as  C— 130,  SRR, 

MRS,  A-10,  KC-135,  F-111,  EA6B,  etc.). 

The  next  step  in  system  evolution  was  an  expansion  to  include 
helicopter  functions  such  as  flight  displays,  engine  displays, 
caution/waming/ advisory  svibsystems,  electrical  systems  (circuit  breakers) , 
and  a  large  number  of  controls/displays  referred  to  as  secondary  systems. 
This  step  was  accomplished  by  addition  of  the  items  shown  in  Figure  3.  The 
crew  interfaces  for  the  functicxis  absorbed  are  four  multi-function  displays 
(MFD's)  and  two  keyboard  terminal  units  (KTU's) .  Eight  remote  terminals 
provide  interface  to  the  many  hundreds  of  aircraft  sensors,  transducers, 
etc.  Generation  of  alphanumerics  and  vector  graphics  are  accomplished  in 
two  prograitmable  syitibol  generators  (PSG's).  The  processing  elements  consist 
of  two  Sperry  SDP-175  16-bit  processors.  Rrograimiing  is  still  generally  in 
assembly  code;  however,  concepts  such  as  structured  software  with  software 
modules  are  evolving.  Architecturally,  the  system  can  be  described  as  of 
modest  data  rates,  fully  redundant,  and  through  use  of  dynamic  bus 
allocation  (DBA)  semevhat  partitioned  software  (i.e.,  for  a  fixed  time 
period  of  every  frame  the  master  bus  controller  in  one  of  the  SDP-175 's 
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Figure  3,  Expansion  to  Include  FUght/Englne/ 
Caution/Waming,  etc. 


Figure  4.  Voice  Interactive  Avionics  and  Airborne 
Target  Handoff  System  Added 


relinquishes  the  bus  to  the  CNI  si±>set  at  vhich  time  all  CNI  traffic  is 
acccrrplished) .  This  architecture  (with  sane  hardware  optimization  vhich 
eliminates  the  need  for  DBA)  is  currently  being  applied  to  systems  such  as 
the  OH-58D  ard  the  HH-60D.  The  Amy  Avionics  Laboratory  (see  referenced 
paper)  is  now  adding  Voice  Interactive  Avionics  (VIA) ,  both  synthesis  and 
recognition,  and  a  digital  data  link,  the  Airborne  Target  Handoff  System 
(ATHS),  to  the  system  (see  Figure  4). 


4.3  The  Near  Futvire 

In  addition  to  adding  these  new  functions,  it  has  becone  apparent  that 
through  additional  processing  a  much  higher  level  of  automation  can  be 
introduced  into  this  system.  If  it  is  assumed  that  this  new  processing  is 
to  be  implemented  using  the  new  DOD  standard  Higher  Order  Language  (HOL) , 
Ada,  and  the  processor  used  is  to  be  characterized  by  a  standard  Instruction 
Set  Architecture  (ISA),  suc±i  as  MIL-STD-175QA  for  16-bit  machines  or 
MIL-STD-1862  for  32-bit  machines,  then  the  addition  of  a  processor  as  shown 
in  Figure  5  beccmes  very  appealing.  (For  illustrative  purposes  only  one 
processor  is  shown;  however,  in  reality  there  WDUld  be  redundancy.)  Now 
further  assiaming  that  all  the  necessary  software  tools  are  mature  enough  to 
distribute  to  the  engineering  elements  that  have  cognizance  over  the  subsets 
of  this  system,  the  processing  functicais  currently  embedded  in  the  CNI 
subset  and  the  SDP-175 '  s  can  be  placed  in  software  modules  vhich  can  then 
reside  in  the  new  processor.  Only  a  nradest  amount  of  processing  would 
remain  outside  this  new  processor  (input/output,  signal  conditioning,  syiibol 
generation,  etc . ) . 

If  attention  is  now  turned  to  the  architecture  evolving  in  the 
navigation  technology  area,  a  virtual  step-by-step  analogy  will  occur 
resulting  in  expansion  of  the  system  to  that  shown  in  Figure  6.  Similar  to 
the  basic  aircraft  area,  by  the  addition  of  processing,  a  much  higher  level 
of  synergism  can  be  achieved  among  the  navigation  elements.  Ihe  processor 
shown  at  the  bottan  of  the  navigaticai  subset  data  bus  in  Figure  7  is,  of 
course,  identical  to  the  basic  aircraft  processor  just  discussed  (HOL,  ISA, 

35 


Figure  7.  Navigation  Systan  Procesaing 


Figure  0.  Hlgn  Speed  Bua 
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structured  prograitiming,  etc.)*  In  actual  fact,  they  could,  of  course,  be 
the  same  processor  or  maybe  two  processors  residing  in  the  same  box 
interconnected  by  a  high  speed  bus  ( see  Figure  8 ) .  Nevertheless ,  the 
important  point  at  this  time  is  to  note  that  all  systan  level  processing 
software  vdll  be  in  a  higher  order  language  (Ma)  and  will  be  in  modular 
form. 


A  further  analogy  (Figure  9)  can  new  be  made  for  the  system  level 
processing  in  the  various  functional  areas  such  as  flight  control,  fir 
control,  stores  management,  target  acquisition,  visionics,  aircraft 
survivability  equipsnent,  etc.  That  is  to  say,  in  each  of  these  areas, 
system  level  processing  functions  would  be  developed  using  the  same  software 
tools  and  the  same  software  structure. 

Now  each  of  these  functional  areas  will  require  unique  crew  interface 
actions  which,  although  developed  separately,  must  be  mapped  into  the  total 
cocT<pit.  During  developnent  of  these  various  subsystems,  seme  crew 
interface  software  and  hardware  must  be  developed  and  used  to  accatplish 
many  of  the  necessary  steps  in  subsystem  development.  It  is  inportant  that 
in  this  subsystem  developnent  process  the  control/display  hardware  used  and 
the  software  developed  for  it  be  capable  of  being  mapped  into  a  totally 
integrated  coc]q>it  (i.e.,  minimize  hardware  uniqueness/use  softweire 
modules).  Now  assuming  a  separate  cocl<pit  data  bus  (see  Figure  10),  and  for 
illustrative  purposes  cinother  processor,  the  crew  interface  software  frem 
the  various  subsets  can  now  be  mapped  into  this  processor  at  the  time  of 
total  systan  integration. 

A  structure  has  now  been  created  vhich  allows  the  various  functional 
areas  to  develop  hardware  and  software  independently,  albeit  under  cejrtain 
constraints,  yet  also  prepares  for  total  system  integration.  Briefly 
stated,  the  constraints  would  be:  to  write  all  system  level  software  in  an 
HOL  in  accordance  with  a  priori  established  rules,  eliminate  system  level 
processing  in  the  various  sensors,  and  to  use  generic  control/display 
heurdware  during  development  that  is  a  functional  subset  of  this  total 
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coc'kpit.  Further,  bus  <X)ncepts  that  are  evolving  wDuld  treat  the  data  bus 
interface  as  any  other  interface  tied  to  the  imiltiprocessor  global  bus 
thereby  making  the  data  bus  transparent  to  future  high  speed  data  bus 
standards.  As  shown  in  Figure  11,  the  various  data  buses  would  be 
geographically  distributed  on  an  airframe  at  the  time  of  total  system 
integration  even  though  developnent  of  the  sv±)systems  used  functional 
distributions.  Finally  the  multiprocessor  vrould  exhibit  certain 
characteristics  such  as  a  globed  memory  tied  to  the  global  bus,  local  memory 
with  each  microprocessor,  and  a  very  high  speed  interface  by  vhich  a  global 
bus  in  one  multiprocesscar  can  be  tied  to  the  global  bus  of  another 
multiprocessor  vhich  is  executing  other  functions  or  possibly  the  same 
functions  because  of  fault  tolerant  considerations. 


4.4  A  Few  Years  Hence 

The  multiprcx^essor/multibus  architecture  evolved  is  in  essence 
technology  transpeurent ;  however,  a  few  points  must  be  made  with  regard  to 
further  evolution  that  includes  hardware  technology  (such  as  VHSIC  chips) 
aM  softv/are  technology  (such  as  sensor  fusion  algorithms).  Assuming  that 
some  of  these  prcxiessing  functions  v/ill  be  located  in  special  modules  (e.g., 
signal  prcxiessors)  also  tied  to  the  processor  global  bus,  it  beexomes 
necessary  to  create  a  means  vhereby  the  very  v/ide  bandwidth  data  from  the 
sensors  can  be  fed  to  these  modules.  This  can  be  achieved  via  direct  ports 
to  the  multiprocessor  or  if  fault  tolerant  designs  are  to  be  achieved  a  very 
high  speed  sensor  data  bus  may  have  to  be  synthesized.  Much  thought  is 
currently  being  focused  on  this  area  and  a  number  of  ccxicepts  cure  evolving. 
The  U.S.  ArttY  Avionics  Laboratory  is  pursuing  a  number  of  studies  to 
determine  vhich  of  the  concepts  are  applicable  to  helicopter  systems. 
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4.5  Conclusicai 


The  concepts  presented  in  this  paper  represent  an  attenpt  to  arrive  at 
an  architecture  vhich  fits  the  avionics  technology  available  today  and  that 
which  will  be  available  in  the  near  future.  Current  efforts  to  inplement 
this  technology  in  the  U.S.  Amy  Avionics  Laboratory  are  using  currently 
available  microprocessors  configured  as  a  multiprocessor  and  an  available 
Ada  cotpiler.  A  procuranent  strategy  has  evolved  in  parallel  with  this 
architecture  that  uses  form,  fit,  function  specifications  and  interface 
control  documents  so  as  not  to  restrict  future  procurements  to  today’s 
technology.  Certainly  much  work  remains  to  be  acccmrplished  to  evolve  the 
concept  presented  here;  however,  it  is  fully  expected  that  over  the  next 
several  years,  enough  experience  will  be  gained  to  achieve  an  architecture 
that  will  meet  the  needs  of  the  demanding  helicopter  missions  of  the  future. 
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Chapter  5 


TEffi  F-16  AVIONICS  MULTIPLEX  SYSTEM 

5.1  F-16  MULTIPLEX  SYSTEjyi 

The  F-16  developnent  program  coincided  closely  with  the  initial 
piiblicaticxi  of  1553  (USAF)  and  the  F-16  then  became  the  first  vehicle  to  use 
and  flight-test  a  1553  (USAF)  carpatible  multiplex  data  bus  system. 

The  F-16  data  bus  syston  is  characterized  by  an  extremely  simple 
approach  to  architecture,  bus  control,  redundancy  management,  mechanization, 
and  bus  control  transition  technique. 

5.1.1  application  Area 

The  F-16  data  bus  is  basically  limited  to  the  avionic  system  (AMUX) 
with  essentially  all  major  avionic  subsystans  using  the  bus  for  data 
transfer.  In  fact,  the  cxily  major  sv±)system  absent  is  the  flight  cxxitrol 
system. 

Nine  different  avionic  subsystems  interface  directly  to  the  F-16  data 

bus: 

a.  Fire  control  ccrtputer  (FCC) 

b.  Fire  control  and  navigation  panel  (FCNP) 

c.  Inertial  navigation  unit  (INU) 

d.  Fire  control  radar  (FCR) 

e.  Radar  electro-optical  display  (REO) 

f.  Central  air  data  ccnputer  (CADC) 

g.  Head-up  display  (HUD) 

h.  Stores  management  set  (9^) 

i.  Ihrget  identification  set,  laser  (TISL) 
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Figure  5-1.  F-16  Multiplex  System  Architecture 


All  electronics  required  to  interface  with  the  multiplex  bus  are 
ccaitained  within  the  respective  subsystem,  thus  ccnpletely  eliminating  the 
need  for  stand  alcne  ratote  terminals  (RT)  or  external  signal  conditioners. 
Thus,  each  subsystan  provides  data  in  digital  form  to  the  bus  interface 
internal  to  the  systan,  the  only  external  signal  interface  being  the  serial 
multiplex  bus . 

5.1.2  System  Architecture 

Ehysiccil  architecture  of  the  F— 16  aviCTiic  data  bus  system  is  diown  in 
figure  5-1.  A  dual  redundant  bus  network  is  used  primarily  to  prevent  a 
single  bus  fault  (cable  or  ccxmector)  frcm  rendering  the  systan  inoperative. 
With  the  exception  of  -aie  SMS,  none  of  the  si±»systems  has  functional 
redundancy.  The  SMS  has  two  identical  cotputers  housed  in  one  line 
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replaceable  unit  (LRU) .  Each  ccnputer  is  connected  to  c*ie  of  the  1553  buses 
through  its  own  1553  interface. 

The  F-16  data  bus  system  was  designed  to  be  caxpatible  with  the 
interface  requirements  of  1553 (USAF).  The  F-16  data  bus  syston  contains  few 
actual  deviations  from  1553 (USAF).  Most  would  be  more  accurately  classified 
as  clarifications  or  additions  to  the  original  (no  revision)  standard. 


5. 1.2. 3  Multiplex  Cable  Assembly 

The  F-16  data  bus  uses  a  very  short  cable  assembly.  Although 
1553 (USAF)  allows  tp  to  300  ft  of  cable,  the  F-16  main  bus  is  only  30  ft 
long.  All  siibsystems  are  attached  to  the  bus  ty  stubs  vhich  are  connected 
to  the  main  bus  by  transformer-resistor  coupling  networks.  Except  for 
provisions  for  the  TISL  system,  the  stiabs  vary  in  length  frcm  approximately 
2.5  ft  to  16.7  ft.  The  TISL  provision  includes  a  22.5  ft  stub  to  an 
externally  mounted  PAVEPE1!®3Y  pod. 


5. 1.2. 4  Bus  Protocol 

The  functional  architecture  of  the  F-16  multiplex  data  bus  system  is 
shown  in  figure  5-2.  All  transactions  are  ccmnand/response  with  bus  control 
centralized  in  the  PCC.  A  backv^)  bus  control  capability  resides  in  the  INU. 
Controller-to-terminal,  terminal-to-controller,  and  terminal-to-terminal 
exchanges,  as  defined  ty  1553,  are  used.  Terminal  addresses  are  hard  wired 
within  the  remote  terminals.  Any  subsystem  is  capable  of  receiving  a 
carmand  on  either  bus  at  any  time.  A  subsystem  always  acts  on  the  latest 
ccnmand  word  received.  If  a  second  cortmand  word  is  received  (on  either  bus) 
vhile  a  previous  message  is  being  received,  the  svibsystem  interrupts  receipt 
of  the  first  message  and  accepts  the  latest  carmand.  This  feature  also 
allows  a  transmission  cn  one  bus  to  be  interrvpted  by  a  subsequent  carmand 
on  the  second  bus. 
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FCNP 


Figure  5-2.  F-16  Multiplex  Data  Bus  functional  Block  Diagram  (Primary  Mode) 


All  bus  transactions  are  strictly  sciheduled  by  the  FCC.  Interrupt 
servicing  as  such  is  not  allowed,  but  special  servicing  may  be  requested  by 
a  status  word  during  a  regular  transaction. 

Invalid  Manchester  word  synchronizatiai  is  used,  with  all  stibsystoiis 
using  individucil  asynchronous  clocks.  A  degree  of  synchronous  operation  is 
also  possible  as  the  central  controller  has  the  capability  to  camiand  all 
terminal  clocks  to  reset  simultaneously.  However  tdiis  capability  is  not 
presently  used.  Instead,  time-critical  data,  such  as  inertial  platform 
measurements,  is  transmitted  with  a  time  tag  so  that  individual  users  may 
establii^  latency  of  this  data. 

The  use  of  time  tag  or  algorithmic  ccnpaisation  has  proved  to  be 
entirely  satisfactory  in  removing  the  few  variable  latency  problems 
encountered,  thereby  preserving  the  inherent  sinplicity  of  asynchronous 
(operation. 
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Messages  are  transmitted  in  blocks  ranging  fran  1  to  32  data  words. 

The  basic  message  transfer  rate  is  50  Hz  with  slower  rates  available  in 
powers  of  twa  submltiples .  The  lowest  data  rate  is  1.5625  Hz.  Therefore, 
the  major  frame  rate  is  640  ms. 

Command,  status,  and  data  word  formats  are  as  shown  in  figure  5-3.  The 
cottmand  word  is  ccnposed  of  a  sync  waveform,  subsystem  address, 
transmit/ receive  bit,  subaddress/mode  field,  data  word  count,  and  a  parity 
bit.  Status  word  bit  assignments  are  as  shown.  The  data  quantity,  response 
error  and  addressing  error  bits  (designated  by  *  in  fig.  5-3)  are  always 
transmitted  as  O's  on  the  bus.  The  bits  may  be  set  in  the  status  word  by 
the  bus  controller  (FGC)  after  the  word  is  received  as  an  internal  record  of 
detected  message  ccmpletion  failures  in  RT-to  controller  transfer. 

The  subaddress/mode  field  in  the  conmand  word  is  used  to  indicate 
sijbaddress  ca:  functioo  commands  per  1553.  Subaddresses  are  used  to  identify 
specific  data  blocks  to  be  transferred.  Function  ccrtmands  are  indicated 
vhen  the  siibaddress/mode  field  contains  all  logic  I’s. 

Only  two  function  corantiands  (mode  codes)  are  used  by  the  F-16.  These 
assignments  are  shown  in  figure  5-4.  The  transmit  status  command  (00000) 
causes  the  subsystem  to  reset  and  initialize  its  receiver  logic  and  respond 
with  its  status  word  only.  In  addition,  if  a  subsystem  receives  a  function 
ccmmand  (mode  code)  with  any  bit  pattern  other  than  00000  or  00001,  the 
transmit  status  ccmmand  is  assumed. 


5.1.3  System  Control 

The  F-16  multiplex  data  bus  system  uses  a  simple  control  philosophy. 
The  FCC,  vhen  operating,  acts  as  the  bus  controller.  If  the  POC  is  not 
operating,  the  INU  assumes  bus  control.  This  concept  is  further  simplified 
by  the  restricticxi  that  the  FCC  can  never  operate  as  a  ramote  terminal. 
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Command 

Word  count  field  (Bit  time) 

interpretation 

15 

16 

17 

18 

19 

Transmit  status 

0 

0 

0 

0 

0 

Reset  timer 

0 

0 

0 

0 

1 

Note:  Any  other  bit  pattern  will  cause  RT  to  "transmit  status." 


Figure  5-4.  F-16  Function  Vford  Comnands  (Mode  Cedes) 


5. 1.3.1  Fault  Isolation  and  Redundancy  Management 

All  bus  control  is  based  on  the  ability  bo  ccmnunicate .  Ccmnunication 
status  assessment  is  established  through  periodic  polling  of  each  terminal. 
Polling  occurs  at  the  basic  frame  rate  of  1.5625  Hz.  Based  oci  the  polling 
results  data  transfer  with  a  subsystem  is  either  established  or  deleted.  If 
a  subsystem  responds  to  a  poll,  data  cciiiiiunications  are  established.  If  the 
siibsystem  fails  to  respond  for  two  consecutive  polling  periods,  that 
subsystem's  data  transfer  ccitinands  are  deleted  from  the  controller's  current 
centnand  table.  Ihus,  periodic  polling  allows  a  siibsystem's  ccmnunication 
status  changes  to  be  discerned  without  reference  to  einy  additional  input. 

Ihe  ability-to-ccmmunicate  approach  also  results  in  one  of  the  siirplest 
strategies  possible  for  selecticxi  of  the  redundant  channel.  The  controller 
sinply  always  uses  the  channel  that  worked  last.  For  exairple,  a  successful 
transfer  cn  bus  A  woiold  result  in  the  next  transfer  of  the  same  block  also 
being  attenpted  on  bus  A;  however,  if  the  first  attenpt  on  bus  A  failed, 
then  the  retry  of  that  transmission  vould  be  attenpted  cn  bus  B.  Ihus, 
ccmnunicatiais  will  continue  on  the  channel  that  is  functioning.  Note  that 
the  retry  is  limited  to  once  per  scan  of  the  cenmand  table  and  is  cilvra.ys 
initiated  on  the  alternate  bus.  If  the  retry  fails,  the  cxitmand  is  skipped. 
The  sequence  is  "fail  once,  retry  on  ailtemate;  fciil  twice,  go  to  next 
command." 
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5. 1.3. 2  Primary  and  Backup  Control 


The  F-16  FOC  normally  functions  as  bus  controller.  In  case  of  an  FCC 
power  down  or  self-test  failure,  bus  control  is  assumed  by  the  INU.  Once 
again,  the  sinplicity  of  the  F-16  AMUX  system  is  apparent  in  the 
mechanization  of  the  bus  control  transition  technique.  If  the  FCC  is 
powered  down  or  beccmes  inoperative,  bus  control  is  passed  to  the  INU  by  a 
single  discrete  between  the  two  lanits.  During  operation,  the  INU 
periodically  saitples  the  discrete  for  a  high-voltage  or  high-iirpedance 
conditicn.  If  two  consecutive  samples  are  in  the  pass  control  or  NO-GO 
state,  the  INU  assumes  bus  control  responsibilities.  The  INU  then  continues 
periodic  saitpling  of  the  discrete  and  relinquishes  control  to  the  FCC 
imnediately  i:pon  detection  of  a  low-voltage  GO  condition  on  the  discrete. 

Bus  control  is  greatly  sirrplified  in  the  backup  mode  because  the  FCC 
and  TISL  are  cotpletely  eliminated  fron  the  system.  This  is  appeurent  by 
ccttparison  of  the  backup  functional  interface  shown  in  figure  5—5  with  that 
of  the  primary  mode  (fig.  5-2). 


5.1.4  Bus  Controller 

The  Fee's  proninence  in  the  primary  data  flow  pattern  (see  fig.  5-2) 
figured  heavily  in  the  selectioi  of  the  FCC  as  the  primary  bus  controller. 
Also,  General  Dynamics  was  responsible  for  developing  the  operational 
software  for  the  FCC,  thus  ensuring  that  the  prime  contractor  maintained 
responsibility  for  system  integration. 

Again  referring  to  figure  5—2  and  following  the  previously  established 
line  of  reasoning,  it  became  apparent  that  the  INU  would  figure  most 
prcminently  in  the  data  flew  pattern  should  the  FCC  fail.  Therefore,  the 
INU  was  selected  to  perform  the  backup  bus  control  function. 


5. 1.4.1  Primary  Bus  Control  Itqplenien.tat.ion 

Primary  bus  control  resides  in  the  POC.  The  POC  is  a  Delco  M362P 
coiputer  procured  for  the  P-16  and  progranmed  ty  Genereil  Dynamics.  Act\jal 
bus  control  is  maintained  by  a  micrqprograitniable  hardware  ccaitroller  that  is 
initiated  periodically  by  the  POC  operationeil  flight  program  (OPP) .  This 
controller,  Ccilled  the  serial  data  interface  (SDI)  reads  and  executes  bus 
transfer  sequences  stored  in  the  POC  madn  memory.  Cnee  initiated  by  the  POC 
OFP  software,  the  SDI  will  ccxitinue  to  read  and  execute  the  coranand  table 
vintil  either  (1)  the  coimand  sequence  is  ccqplete  or  (2)  a  transmission 
fails  to  coiplete  successfully.  Software  intervention  is  required  only  to 
start  the  SDI  processor,  analyze  poll  responses,  and  to  process 
SDI-initiated  interrx^Jts  such  cis  "coranand  failure"  or  "coranand  task 
conplete."  A  coranand  fedlure  interrrpt  is  generated  to  the  CFU  vdien  any 
corananded  bus  transmission  fails  to  complete  successfully.  A  coranand  task 
corplete  interrxpt  is  used  twice  per  minor  frame:  (1)  to  inform  the  OPP 
that  key  input  data  has  been  received  and  (2)  to  indicate  that  all  scheduled 
transfers  for  the  current  time  frame  have  been  conpleted.  Ihe  first 
interrupt  may  be  generated  after  any  designated  SDI  coranand. 
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Figure  5-6.  Bus  tontrol  Cotmand  Table  Structure 

In  addition  to  data  transfers,  the  SDI  nay  also  be  catmanded  (by  the 
OFF  software)  to  perform  various  internal  functions  such  as  ccitnand  sequence 
■branches,  internal  self— test,  or  SDI  stop. 

The  OFF  ccxitrols  data  transfers  using  a  time-slice  executive  structure 
operating  at  a  50-Hz  naximum  ccnpatational  rate.  The  SDI  thus  is  ccninanded 
to  initiate  a  transfer  sequence  once  per  20  ms  minor  frame.  Actual  avionic 
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interface  data  are  structured  into  blocks  with  fixed  transfer  rates  that  are 
powers  of  two  subnultiples  of  the  basic  50-Hz  rate.  Therefore,  the  ccnmand 
sequence  in  each  minor  frame  will  consist  of  data  blocks  frori  the  50-Hz 
group  plus  blocks  fron  caie  of  the  submultiple  groups.  Because  the  lowest 
transfer  rate  is  1.5625  Hz,  640  milliseconds  cire  required  to  cottplete  a  full 
data  transfer  sequence  (major  frame) . 

This  periodic  transfer  sequence  is  irtplemented  by  linking  the  SDI 
contnand  table  prior  to  each  minor  frame.  This  is  acccnplished  by  setting 
two  link  ccximands  to  provide  the  desired  path  through  the  connand  table 
(fig.  5-6) .  The  content  of  the  ccmtiand  table  is  modified  by  the  results  of 
poll  processing  to  eliminate  the  transfer  ccnmands  of  those  subsystems  that 
are  not  actively  ccrnnunicating. 

Polling  is  accottplished  at  the  major  frame  rate  of  1.5625  Hz  to  ensure 
that  satisfactory  cxirmunication  can  be  established  with  a  terminal  before  a 
data  transfer  is  atteirpted.  Polling  is  accxatplished  using  the  F-16 
dedicated  function  (mode  code)  contnand,  vhich  requests  the  addressed 
terminal  to  respond  with  its  current  status  word  only.  The  dedicated 
functicn  contnand  is  distinguished  by  all  "I's"  in  the  subaddress/mode  field. 

Any  poll  ccntnand  that  fails  (vhether  because  of  a  reported  fault  status 
car  a  transmissiai  failure)  causes  a  CPU  interrupt  and  siibsequent  software 
recording  of  the  poll  cxxnnand  feiilure.  The  result  of  each  subsystem  poll  is 
then  masked  with  the  results  of  the  previous  poll  and  used  to  delete  the 
data  transfer  for  that  subsyston  fron  the  ccnmand  table  if  two  successive 
poll  failures  are  recorded.  The  next  successful  poll  response  frcm  that 
sv±)system  will  inmediately  reinstate  the  transfer  cxxtmand  and  so  reestablish 
ccnmunicaticxi  with  the  polled  si±)system. 

In  addition  to  poll  response  errors,  data  transmission  errors  also  are 
handled  by  special  error-handling  interrupt  software.  The  error-handling 
software  indexes  an  error  response  table  that  determines  the  appropriate 
error  response  for  each  ccnmand.  The  error  response  table  will  indicate  (1) 
vhether  the  ccnmand  is  to  be  retried,  (2)  the  bus  to  be  used  for  the  retry, 
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and  (3)  vdiether  the  transmitted  data  (if  any)  should  be  invalidated.  As 
previously  noted,  all  retries  are  currently  initiated  on  the  alternate  bus, 
but  sufficient  software  flexibility  exists  to  allow  the  retry  mode  to  be 
selectively  changed  cxi  an  individual  ccttmand  basis  if  so  desired.  The  FCC 
used  950  16-bit  words  of  memory  for  bus  control.  This  includes  the  conplete 
control  algorithm  for  (1)  SDI  start  ccmnands,  (2)  interrupt  handler  for 
conmand  link  selection,  (3)  error  interrupt  handler,  (4)  poll  analysis 
module,  and  (5)  bus  catmand  tables.  CPU  processing  time  cotprises  less  than 
2%  of  the  rtachine  duty  cycle. 


5. 1.4. 2  Secondary  Bus  Control  Implementation 

Secondary  or  backup  bus  control  is  provided  Iy  'tii®  INU.  The  INU 
periodically  samples  the  bus  control  discrete  fron  the  FCC  and  assumes  bus 
control  after  two  consecutive  NO-GO  samples.  The  basic  bus  control  concept 
used  by  the  INU  is  essentially  the  same  as  that  previously  discussed  for  the 
primary  controller.  The  backup  control  algorithm,  hcwever,  is  considerably 
simpler  than  that  of  the  primary  system  for  two  reasons.  First,  the  numiber 
of  data  blocks  to  be  managed  is  imuch  smaller.  Second,  fault  reporting  and 
error  recovery  requirements  are  considerably  reduced.  The  INU  contains  a 
hardware  EMA  controller  that  is  ccmmanded  by  the  INU  OFP  software  in  the 
same  manner  as  the  FCC.  The  only  difference  in  implamentation  is  that 
backup  redundancy  management  is  hardware  controlled  by  the  INU,  vhereas  OFP 
software  in  the  FCC  controls  redundancy  management  in  the  primary  bus 
control  mode. 

5.1.5  Eertote  Terminal 

The  F-16  multiplex  data  bus  system  interfaces  with  and  provides 
ootplete  conmunication  with  nine  major  subsystems,  as  listed  in  section 
5.1.1.  All  bus  interfaces  are  integral  to  the  subsystems  they  serve.  This 
approach  drastically  reduces  integration  problems  associated  with  standalone 
ft/ signal  conditioning  systems. 
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of  the  nine  subsystems,  seven  always  act  as  RT's  only.  Cne,  the  FCC, 
acts  as  the  prijnary  bus  controller  and  is  deleted  from  systen  ccnmunication 
in  the  bachup  mode.  It  can  never  act  as  a  RT.  The  INU  can  act  as  either  a 
RT  (in  the  primary  mode)  car  a  bus  controller  (in  the  secondary  mode). 


5. 1.5.1  Subsystem  Interface 

Because  all  bus  interfaces  are  integral  to  the  si±>systems  that  they 
serve,  the  usual  subsystem  interface  is  solely  the  responsibility  of  the 
avionic's  supplier  and,  in  fact,  does  not  exist  external  to  the  subsystem. 
Thus,  the  ccmnunicatioi  interface  with  the  si±)system  is  limited  to  the  1553 
bus.  None  of  the  F-16  subsystems  use  a  standard  interface  module.  Ihe  bus 
interfaces  within  the  various  subsystems  represent  independent  designs  by 
six  different  si:ppliers. 


5. 1.5. 2  Fault  Isolation  and  Redundancy 

Although  the  F-16  has  a  dual  redundant  bus  network,  only  the  stores 
management  set  is  fully  dual  redundant.  None  of  the  other  subsystems  have 
functional  redundancy.  The  SMS  utilizes  two  identical  AMUX  interface 
modules.  Ehch  AMUX  module  serves  one  redundant  half  of  the  SMS  and 
ccrtmunicates  with  one  of  the  two  data  buses. 

Fault  conditions  within  a  subsystem  vdiich  could  affect  data  validity 
are  "OR'ed"  into  a  single  terminal  status  bit  vihich  is  returned  in  the 
status  word.  Fault  conditions  included  in  the  terminal  status  bit  are 
determined  on  an  individual  subsystem  basis.  The  basic  ground  rule, 
however,  is  that  to  be  included  in  the  terminal  status  bit,  the  failure  must 
affect  validity  of  all  data  transmitted  ly  the  subsystem.  Other  fault 
conditions  are  detected  by  the  system  controller  based  on  ability  to 
ocmnunicate. 
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A  1553  feature  that  is  int^^lemented  in  each  F-16  terminal  is  "operation 
on  latest  comend  word."  Ihis  feature  requires  that  a  terminal  act  on  the 
latest  coinnand  word  received  on  either  bus  even  though  it  may  interrupt 
receipt  or  transmission  of  a  message  in  progress.  A  message  being  received 
may  be  interrupted  cn  either  bus.  A  message  being  transmitted  may  be 
interrupted  by  a  ccttmand  on  the  alternate  bus.  This  is  the  only  oondition 
in  the  F-16  systan  under  vhich  both  buses  may  be  in  use  simultaneously, 
dhis  feature  is  potentially  useful  as  a  priority  override  or  to  shut  down  a 
faulty  transmitter. 

A  terminal  status  word  only  may  be  requested  from  an  individual 
terminal  by  use  of  the  dedicated  function  cormand  designated  by  an  all  I's 
sribaddress/mode  code  field,  as  described  in  section  6. 1.2. 4. 
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Section  II 

System  Test  Activities 
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Chapter  6 


MULTIPLEX  SYSTEM  TEST 


Tests  of  1553  aircraft  data  bus  system  will  take  place  (1)  at  the 
facilities  of  suppliers  of  LRU's  with  1553  interfaces,  (2)  at  a  "hot  bench" 
generally  located  at  the  airplane  ccnpany,  and  (3)  during  flight  test. 
Flight  tests  will  usually  be  conducted  near  the  airplane  ccrtpany  and 
possibly  at  military  bases  and  other  locaticsis  ty  the  eventual  military 
using  ccttmand.  the  purpose  of  this  section  is  to  briefly  describe  hardware, 
test  procedures,  and  test  philosophy  of  the  various  levels  of  testing  that 
have  been  found  useful  for  test  of  1553  data  bus  systems. 


6.1  Scope  of  Tests 

Data  bus  interfaces  are  not  usually  designed,  developed,  and  tested 
independently  of  all  other  LRU  interfaces.  Although  the  discussion  centers 
on  tests  of  subsystems  with  1553  interfaces  and  system  test,  it  should  be 
understood  that  many  other  design  and  test  activities  are  rec[uired  to 
successfully  ccrtplete  avionics  integration  for  an  airplane.  The  1553 
terminal  design  and  test  form  a  part  of  these  activities.  This  is  so 
because  1553  defines  a  terminal  as:  "The  electronic  module  necessary  to 
interface  the  data  bus  with  the  siibsystem  and  the  subsyston  with  the  data 
bus."  Tests  of  subsystems  connected  to  the  1553  data  bus  usually  include 
verification  of  interface  functicns  on  the  subsystem  side  as  well  as  the  bus 
side  of  the  terminal. 

Design  verification  tests  of  1553  terminals  are  an  inportant  part  of 
system  and  subsystem  design.  Table  6-1  is  a  sunmary  of  design  procedures. 
Table  6—2  is  a  suitinary  of  test  procedure  development.  Each  table  is  divided 
into  two  parts,  procedures  for  the  subsysten  side  as  well  as  the  bus  side  of 
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the  terminal.  The  procedures  presented  in  the  t^les  should  be  used  to 
scope  the  test  activities. 


1 .  Design  procedures  for  avionic  subsystem  interface  to  remote  terminal  (RT): 

a.  The  Government  or  the  integration  contractor  will  provide  the  standard  interface  modules'  (IMy  definition 
to  the  avionic  contractor,  when  standard  I  M's  are  used. 

b.  Contractor  will  develop  the  electrical  interface  definition  between  the  avionic  subsystem  ahd  the  RT  IM. 

c.  Perform  an  engineering  design  of  the  electrical  interface, 

d.  Manufacture  the  breadboard  to  accommodate  a  standard  IM. 

e.  Develop  support  test  equipment  to  generate  the  IM  interface  input  and  output  signals, 

I  ■ 

f.  Define  acceptance  test. 

g.  Perform  acceptance  test. 

h.  Evaluate  test  results. 

i.  Report  out-of*limits  conditions  for  failed  test. 

j.  Apply  test  results  to  reevaluate  and  improve  interface  performance. 


2.  Design  procedures  for  avionic  subsystem  interface  to  MIL-STD-1553  bus: 

a.  Evaluate  Interface  definition  of  chosen  avionic  subsystem. 

b.  Design  and  develop  the  electrical  interface  definition  between  the  avionic  subsystem  and  the  1 553  bus. 

c.  Design  a  bus  interface  unit  and  subsystem  interface.  -  . 

d.  Develop  support  test  equipment  to  generate  the  subsystem  and  bus  input  and  output  signals. 

e.  Define  acceptance  test.  ' 

f.  Perform  acceptance  test. 

g.  Evaluate  test  results. 

h.  Report  out-oMimits  conditions  for  failed  test. 

i.  Apply  test  results  to  reevaluate  and  redesign  interface  performance. 


6.2  Typical  1553  Bus  Checkout  Systons 

The  purpose  of  this  section  is  to  introduce  the  types  of  bus  checkout 
systans  that  are  frequently  used.  Generally,  there  are  three  classes: 

a.  The  bench  or  suitcase  1553  multiplex  bus  tester 

b.  The  entire  avionics  hot  bench 

c.  The  progrartmed  bus  noiitor  for  flight  test 

The  bench  car  suitcase  testers  may  also  be  used  to  support  • 

troubleshooting  during  hot  boich  and  flight  tests. 
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Table  6^2.  Test  Procedures  Guidelines 


1.  Methods  for  developing  test  procedure  for  remote  terminal  (RT)  to  avionic  subsystem  interface: 

a.  Coordinate  with  interface  equipment  designers. 

b.  Identify  subsystem  interface  requirements. 

c.  Determine  nominal  interface  operation. 

d.  Identify  error  modes  and  off-nominal  operations. 

e.  Determine  desired  form  of  test  results. 

f.  Determine  test  equipment  requirements, 

g.  Establish  system  time  lines  within  protocol  constraints. 

h.  Flow  chart  test  requirements. 

i.  Recommend  test  procedures. 

2.  Method  for  developing  test  procedure  for  a  MIL-STD-1553  to  avionic  subsystem  interface: 

a.  Coordinate  with  interface  equipment  designers. 

b.  Identify  subsystem  interface  requirements. 

c.  Determine  nominal  interface  requirements. 

d.  Identify  error  modes  ar>d  off-nominal  operation. 

e.  Determine  desired  form  of  test  results. 

f.  Determine  test  equipment  requirements. 

g.  Establish  system  time  lines  within  MIL-STD-1553  protocol  constraints. 

h.  Determine  MIL-STD-1553  parameters  that  need  testing. 

i.  Recommend  test  procedures. 


6.2.1  Multiplex  Bus  Tester  and  Simulator 

A  simulator  is  a  versatile  data  bus  test  instrument  conpatible  with 
MIL-STD-1553  for  explications  in  the  engineering  laboratory,  in  system 
integraticn  laboratories,  and  as  a  portable  instrument  for  fault  isolation. 

Simulators  have  full  capability  to  act  as  a  bus  controller,  both 
sending  ard  receiving  data  bus  messages.  The  simulator  will  transmit  a 
cotimand  word  and  a  selected  number  of  16-bit  data  vords.  The  cctimand  vord 
is  front  panel  selectable,  and  the  16-bit  field  of  each  data  word  is  loaded 
into  memory  from  the  front  panel  switches.  The  proper  polarity  sync 
patterns  and  parity  bits  are  added  to  each  word  to  provide  the  correct  word 
formats. 


61 


Simulators  also  have  the  features  necessary  to  receive  the  message  fron 
a  ratote  terminal,  corresponding  to  the  camiand  ward  address  that  \/as 
transmitted.  The  unit  will  display  the  status  and  all  data  words  as 
selected  fron  the  front  panel  control  switches. 

Typically  simulators  have  the  cap^ility  to  receive  and  verify  valid 
and  invalid  test  words  and  messages. 


6.2.2  Avionics  "Hot  Bench" 

Hot  bench  is  a  comonly  used  term  to  describe  a  systan  development 
laboratory  (SDL)  or  system  integration  laboratory  (SIL).  Such  SIL's  or 
SDL '  s  provide  simulation  cap>ability  and  data  recording  capability  that  are 
used  in  the  development  of  avionic  hardware  and  software.  To  allow  for 
incremental  testing  of  avionics  interfaces,  simulators  of  airplane 
svhsystems  such  as  the  radar  or  stores  are  used.  The  simulators  provide 
realistic  inputs  and  responses  so  that  dynamic  conditions  may  be  evaluated 
in  the  laboratory.  This  is  in  oontrcist  to  the  capability  of  bench  or 
suitccise  testers,  vhich  usually  can  evaluate  only  a  cciuiiand  and  a  response. 
The  simulators  in  hot  benches  are  a  sxibstitute  for  unavailable  hardware,  and 
an  intermixing  of  prototype  or  production  airplane  hardware  with  simulators 
is  usually  possible.  By  this  means,  airplane  hardware  can  be  incrementally 
added  to  an  avionic  system.  Whenever  the  interface  is  the  1553  data  bus, 
rapid  resubstitution  of  the  simulator  for  the  airplane  hardware  permits  the 
isolation  of  paroblems  or  anomalies. 

Several  benefits  of  integration  with  1553  data  buses  beccme  apparent 
during  system  test.  The  data  bus  approach  requires  integrating  only  one 
electrical  interface  per  subsystem  versus  multipla  interfaces  in  the 
point-to-point  method.  The  single  interface  also  allows  more  of  the 
integration  activity  to  be  done  at  the  subsystem  level  using  one  special 
test  fixture,  vhich  might  be  too  costly  with  many  unique  point-to-point 
interfaces.  Simulating  the  data  bus  interface  of  subsystems  can  easily  be 
dcxie  using  a  ccnputer  with  a  data  bus  interface  as  the  simulator.  The 
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equivalent  simulation  in  a  point-to-point  circhitecture  may  require  several 
special-purpose  interfaces  to  be  developed.  Ihe  data  bus  will  also 
accoTTnodate  unexpected  integration  problems  sucih  as  added  data  words, 
changes  in  update  rates,  and  rerouting  of  data  parameters. 


6.2.3  Bus  Monitor  and  Airborne  Instrumentation 


System  designers  ^ould  m^e  provision  for  the  connection  of  a  bus 
monitor  and  avionics  instrumentation  capability.  Provision  will  usually  be 
a  stub  or  connection  properly  terminated  vAien  not  in  use  on  prototype  and 
test  airplanes.  With  this  connection  available,  a  bus  monitor  may  be  used 
during  flight  test  to  acquire  selected  bus  messages.  Recall  that 
MIL-SrD-1553B  describes  bus  monitor  operation  in  the  following  way: 


A  terminal  operating  as  a  bus  monitor  shall  receive  bus 
traffic  and  extract  selected  information.  While  operating  as  a 
bus  monitor,  the  terminal  shall  not  respond  to  any  message  except 
one  containing  its  own  unique  address  if  cxie  is  assigned.  All 
information  obtained  vdhile  acting  as  a  bus  monitor  shall  be 
strictly  used  for  off-line  applications  (e.g.,  flight  test 
recording,  maintenance  recording  or  mission  analysis)  or  to 
provide  the  bacTc-i^)  bus  controller  sufficient  information  to  take 
over  as  the  bus  controller. 

Bus  monitors  are  usually  itrplemented  using  a  digital  conputer, 
appropriate  memory  for  buffering,  and  magnetic  tape  for  recording.  Several 
sippliers  of  bus  mcxiitors  and  airborne  instrumentation  are  qualified  for 
flight  test. 
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Chapter  7 


F-16  C  &  D  TESTING 


7 . 1  Background 

In  1979,  early  in  the  production  run  of  the  F-16A/B,  the  United  States 
Air  Force  defined  a  program  for  the  continued  expansion  of  F-16 
capabilities.  In  particular,  the  program  vas  intended  to  enable  the  F-16  to 
perform  both  the  night,  low-level,  ground  attack  missicxi,  and  the 
all-weather,  multi-target,  air-to-air  mission,  lb  accoitplish  the  first 
task,  the  future  F-16  viould  utilize  the  Ixm  Altitude  Navigation  and 
Targeting  Infrared  for  Night  (LANTIRN)  system  vhich  incorporates  navigation 
and  targeting  forward  looking  infrared  sensors  and  a  terrain  following 
radar.  An  improved  fire  control  radcu:  would  enhance  both  the  air-to-ground 
and  the  air-to-air  capabilities  of  the  F-16,  and  Advanced  Medium  Range 
Air-to-Air  Missile  (AMRAAM)  would  be  the  beyond-visual-range  weapon.  VJhen 
formalized,  this  enhanconent  plan  was  defined  as  the  three  step  F-16 
Multinational  Staged  Improvement  Program  (MSIP) . 

Stage  I  of  F-16  MSIP  cotmenced  in  mid-1981.  All  F-16A/B  airplanes 
produced  since  that  time  have  structural  and  wiring  provisions  for  the  later 
retrofit  of  advanced  systons.  These  modifications  include  inlet  hard  points 
for  sensor  pods  and  wiring  to  wing  stations  for  future  weapons. 

MSIP  Stage  II  is  the  F-16C/D  airplane  vMch  includes  the  following 
major  changes  from  the  F-16A/B; 


by  Kevin  Dwyer,  General  Eynamics,  Fort  Worth  Division  and  Lt  Ool  Tom 
Meschko,  F-16  CTF,  Edwards  AFB  CA,.  This  text  originally  appeared  in  the 
1984  Report  to  the  Aerospace  Profession,  XXVIII  Synposium  Proceedings, 
Society  of  Experimental  Test  Pilots,  1985. 
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a.  litproved  Cockpit. 


(1)  Upfrcxit  ccxitrols  and  display  for  ccranunication,  navigation, 
IFF,  and  fire  control  ccitputer  interface, 

(2)  Two  CRT  multifunction  displays  (MFD)  for  ocntrol  and  display 
of  sensors,  weapons,  and  stores  management, 

(3)  Wide  field-of-view  head-t^  display  (WFOV  HUD), 

(4)  Data  transfer  equipment  vAiich  lets  the  pilot  "load"  his 
mission  into  the  airplane  via  a  solid  state  cartridge; 

b.  New/litproved  Avionics. 

(1)  APG-68  Radar  increases  detection  and  acquisition  ranges,  and 
adds  Track-While-Scan  and  additional  Air-to-Groimd  modes, 

(2)  Combined  Altitude  Radar  Altimeter  (CARA), 

(3)  Advanced  Stores  Management  Set 

(4)  Expanded  Memory/ Speed  Fire  Control  Ccatputer; 

c.  Airframe  Changes. 

(1)  Structural  provisicxis  for  the  Airborne  Self-Protection  Jammer 
(ASPJ)  system,  including  an  enlarged  vertical  tail  fairing, 

(2)  Main  generator  vpgrade  from  a  40  KVA  generator  (on  F-16A/B 
eiirplanes)  to  60  KVA,  and  the  addition  of  a  10  KVA  standby 
generator  (the  other  features  of  the  F-16A  electrical  system  have 
been  retained) , 
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(3)  Increased  capacity  environmental  control  syston  to  allow  all 
the  avionics  (and  the  pilot)  to  keep  cool, 

(4)  New  main  gear  tires  to  permit  an  increase  of  maximum  teikeoff 
gross  weight  to  37,500  lbs., 

(5)  Revised  leading  edge  flap  schedule  to  reduce  hinge  mcments 
during  maneuvering, 

(6)  Expansion  of  9g  maneuver  envelope  to  26,100  lbs.  gross  weight 
(versus  24,100  lbs.  for  the  F-16A/B) ; 

d.  Mded  Weapons  Carriage. 

(1)  Necessary  interface  for  eiployment  of  the  Imaging  Infrared 
Maverick  (AO^-65D) , 

(2)  Partial  provisions  for  AMRAAM  and  future  weapons. 

Stage  III  of  the  F-16  MSIP  will  be  the  step-by-step  integratiai  of 
future  systems  as  they  become  available. 


7.2  Avionics  Testing 

The  MSIP  II  avionics  tests  are  presented  in  the  context  of  software 
development  "facts  of  life"  and  the  methods  used  by  the  F-16  Combined  Test 
Force  at  Edwards  AFB. 

Conpared  to  the  F-16A/B,  the  MSIP  II,  or  F-16C/D,  software  effort  is 
massive,  having  several  individual  planned  updates  of  over  20,000  words 
vhich  is  on  the  order  of  the  total  number  of  words  in  all  of  the  updates  in 
the  F-16A/B.  It  is  undeniable  that  software  takes  time.  There  is 
significant  lead  time  required  with  designing  and  prograitming  software  just 
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as  lead  time  is  required  for  hardware  development.  For  exanple,  the  lead 
time  required  for  one  thousand  words  of  software  for  the  four  major 
conputers  in  the  core  of  the  F-16C  avionics  ranges  fron  9  months  for  the 
easiest  one,  the  multifunction  display  system,  to  12  months  for  the  expanded 
fire  ccaitrol  cotputer. 


7.2.1  Develcpnent  and  Flight  Test  cycle 

There  are  four  major  steps  in  the  overall  block  release  process; 
design,  programxiing,  integration,  and  than  flight  test.  The  total  time 
required  frcm  the  beginning  of  design  until  the  final  product  comes  out  of 
flight  test  is  two  to  two-and-one-half  years.  Since  the  four  steps  are 
sequential,  personnel  and  resources  used  in  one  step  are  relatively  free  to 
begin  work  on  the  next  block  vdien  they  finish  their  major  effort  on  the 
current  block.  Such  overlapping  permits  blocks  to  be  generated 
approximately  twice  as  fast  as  a  strict  serial  process  would  allow. 
Uhfortunately,  however,  the  overlapping  cannot  reduce  the  time  to  effect 
major  changes  resulting  from  flight  test.  Major  block  1  flight  test 
findings  cannot  be  put  into  the  iimiediately  siibsequent  block  because  the 
design  phase  of  that  block  is  ccnplete  before  the  flight  testing  of  the 
previous  block  is  accoitplished . 

Consequently,  all  the  findings  frcm  block  1  go  into  block  3.  Block  2 
is  almost  an  independent  effort,  though  parallel  and  staggered  a  year  after 
block  1.  The  major  flight  test  generated  changes  frcm  block  2  will  not  be 
incorporated  until  block  4.  The  significant  point  is  that  in  a  large 
program  major  ipdates  and  flight  test  findings  cannot  go  into  production 
until  two  years  downstream. 

It  is  iirportant  to  understand  the  flight  test  cycle  inherent  in  this 
process.  When  a  "finished"  tape  corpletes  system  integration  in  the 
laboratory,  it  is  released  for  flight  test.  In  flight  test,  the  tape  must 
sequentially  undergo  three  basic  phases  of  testing.  The  first  is  pure 
development  vhere  it  is  determined  vhether  or  not  the  tape  sinply  functions 
as  designed;  it  does  not  address  the  merits  of  the  design,  only  that 
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everything  that  is  supposed  to  be  is  there  and  operates  as  designed.  If  any 
part  or  feature  is/does  not,  a  potential  change  candidate  is  generated; 
essentially,  it  is  back  to  the  drawing  boards  for  correction. 

Once  a  tape  gets  through  the  first  phase,  it  advances  to  developmental 
test  and  evaluation  (DT&E) .  In  this  phase  we  test  and  evaluate  the  design, 
its  overall  pjerformance,  and  its  integration,  not  only  frcm  a  system  point 
of  view,  but  also  fran  a  pilot/vehicle  interface  point  of  view.  It  is  also 
in  this  phase  that  full  operability  and  initial  qperational  assessments  are 
made  as  well  as  testing  for  specifications  coitpliance.  Like  features  vhich 
do  not  function  as  designed  in  the  pure  development  locp,  deficiencies  in 
design  or  specification  ccmpliance  also  generate  potential  change 
candidates . 

Once  a  tape  coipletes  the  DT&E  phase,  it  advances  to  the  third  loop, 
the  operational  test  and  evaluation  phase;  it  is  in  this  phase  that  the 
system  is  evaluated  and  tested  to  determine  how  well  it  actually  meets 
overall  missiai  requirements  and  does  the  job  operationally.  Again,  vhen 
identified,  design  and  performance  deficiencies  became  potential  change 
candidates.  Whai  a  tape  makes  it  through  all  three  phases,  it  is  finally 
released  for  production.  As  with  hardware  flight  testing,  all  of  the 
testing  conducted  in  these  three  phases  is  governed  by  test  plans.  Beyond 
that,  however,  the  processes  become  considerably  less  parallel.  There  are 
several  pitfalls  in  the  flight  test  cycle  inherent  to  software  testing, 
vhich  are  not  generally  found  in  hardware  testing. 


7.2.2  Management  of  Configuration 

As  mentioned  above,  each  phase  generates  potential  change  candidates. 
These  potential  change  candidates  must  be  properly  managed.  Otherwise, 
there  is  real  potential  that  items  singularly  identified  in  flight  test  may 
be  incorporated  because  they  are  easy  or  appealing,  but  not  necesseirily  the 
consensus  of  the  entire  participating  test  conntunity.  Corrective  effort  may 
be  expended  without  much  visibility  into  its  overall  inportance  or  its 
relationship  to  the  "big  picture."  This  may  result  in  insufficient  effort 
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on  nore  important  items.  There  is  also  the  risk  of  items  being  discarded  or 
otherwise  lost  because  of  unilateral  determination  that  they  were  not  within 
scope.  There  is  a  tendency  for  only  easy  items  to  get  fixed  vhile  the 
harder  and  maybe  more  inportant  major  items  are  deferred.  And  finally, 
there  is  the  possibility  that  the  items  or  inputs  frcm  the  flight  test  might 
be  misinter-  preted  and,  therefore  be  "fixed"  wrong.  All  of  these  problems 
result  in  valuable  time  lost,  the  possibility  of  the  final  configurations 
being  degraded,  and,  at  the  very  least,  more  cycles  through  the  top  loop. 

In  order  to  effectively  manage  the  change  and  fix  effort,  procedures  to 
formalize,  categorize,  prioritize,  and  track  all  potential  change  candidates 
should  be  applied  in  the  feedback  portion  of  each  loop.  Once  the  change 
candidates  find  their  ways  into  laboratory  integrated,  updated  versions  of 
the  tapje,  another  pitfall  of  software  testing  arises:  inadequate 
configuratiai  control. 

The  major  problem  with  configuration  control  is  insufficient 
documentation — not  documenting  and  keeping  track  of  vhat  actually  is  in  the 
new  tape.  Insufficient  documentation  confuses  the  results.  And  it  is  very 
easy  to  lose  track  of  the  actual  configxiration,  especially  if  you've  had 
several  versicais  varying  frcati  prototype  to  production  in  five  or  more 
si±)systerns .  If  configuration  is  in  question,  results  are  invalid  or 
inconclusive  at  best.  Unless  carplete  refly  is  acccxiplished,  knowledge  of 
the  system  is  poor  and  possibly  could  result  in  a  system  with  insufficiently 
tested  or  even  partially  untested  pjortions  being  released  to  the  field  vhich 
could  ultimately  end  i;p  in  costly  retrofit.  Strict  documentation  of  all 
incorpxarated  changes  is  required  to  naintain  accurate  configuration  control. 


7. 2. 2.1  Functional  Tests 

Because  of  the  extreme  corplexity  of  today's  advanced  integrated 
software  systems  ard  the  proliferation  of  intricate  interfaces  between  the 
various  subystems  and  nodes,  a  fix  or  correction  in  one  area  frequently 
degrades  another  area.  Ikifortuantely,  the  integration  laboratory  does  not 
always  reveal  all  of  the  side  effects.  It  is  inperative,  therefore,  after 
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each  change  or  updated  tape,  that  all  of  the  functional  tests  (i.e.  the  top 
loop)  be  repeated  to  the  functional  tests  (i.e.  the  top  loop)  be  repeated  to 
assure  the  desired  fix(es)  did  not  breah  or  degrade  other  features  or 
functions.  In  ccrrplex  systems,  the  functionals  may  take  several  sorties 
vhich  for  unplanned  updates  are  usually  not  provided  for  in  the  test  plan 
nor  is  the  requirement  to  repeat  nost  if  not  all  of  the  tests  in  the  second 
and  third  phases. 

Because  of  the  extra  requirements  generated  by  unplanned  updates,  these 
should  be  kept  to  a  minimum  and  should  inco3rporate  as  many  fixes  at  one  time 
as  practical.  This  requires  iirplementing  a  control  function  between  the 
ground  integration  phase  and  the  first  phase  of  the  flight  test  cycle. 

Uhfortunately,  the  pitfalls  inherent  to  change  candidates  tend  to 
perpetuate  the  cycle,  and  in  so  doing  generate  yet  another  pitfall:  the 
fly-fix-fly  syndrcme.  Each  unplanned  update  uses  vciluable  time  and  in 
essence  marks  a  new  start.  The  end  date  or  required  delivery  date  seldom 
slips,  however.  This  creates  a  corpression  of  the  available  time  in  vhich 
to  corplete  all  the  planned,  recjuired  tests  and  invariably  leads  to  ein 
ovendielming  sense  of  urgency  and  increased  pressure  to  test  the  latest  fix 
iimediately,  short-circuiting  the  configuration  docunentation  and  ignoring 
the  ccxisequences  of  the  extra  functional  sorties.  The  risk  of  losing 
oonfiguraticxi  control  is  increased  alcaig  with  increased  likelihood  of 
inconplete  or  incorrect  fixes  and  therefore,  even  additional  change 
candidates.  Thus  the  catpression  increases  with  the  need  for  repeating  the 
cycle.  Uicontrolled  fly-fix- fly  ultimately  leads  to  significant  overruns, 
far  too  much  effort  spent  in  the  pure  development  loop,  and  too  little 
effort  spent  <xi  test  and  evaluation,  vhich  itself  results  in  proportionately 
too  much  specification  compliance  at  the  expense  of  testing  and  evaluating 
the  full  operability  aspects.  This  leads  ultimately  to  having  the  true  test 
and  evaluation  done  hy  the  user  and,  most  likely,  results  in  costly 
retrofit. 

In  order  to  preclude  or  minimize  inadequate  ccxifiguration  control  and 
limit  the  fly-fix-fly  syndrcme,  a  control  function  must  be  judiciously 
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exercised  to  assure  accurate  knowledge  of  the  configuraticxi  and  to  regulate 
the  frequency  of  updates  introduced  into  the  first  loop. 


7 . 2 . 2 . 2  Simulation 

An  activity  vhich  offers  potentially  significant  reduction  in  the 
number  of  required  updates  is  developiiental  simulation.  Simulation  cam 
optimize  pilot  interfaces  and  explore  options  vhich  otherwise  must 
eventually  be  dene  in  flight  or  not  at  all.  Simulation  is  also  very 
important  in  minimizing  surprises  in  flight  test  by  reducing  the  number  of 
fixes  and  configuration  problons  before  flight  test.  This  essentially 
minimizes  the  number  of  times  that  a  tape  has  to  go  through  the  first  loop. 
Simulation  is  needed  not  only  early  in  the  design  phase,  but  also  during 
flight  test  to  look  at  the  various  design  options  for  change  candidates 
generated  in  any  of  the  feedback  loops  frem  any  of  the  flight  test  phases. 
A  corprehensively  constructed  software  flight  test  program  might  then 
include  three  flight  phases  governed  by  the  test  plans,  with  appropriate 
procedures  to  coitrol  and  track  the  change  candidates  introduced  or 
redesigned,  with  an  effective  mechnizatiai  to  document  and  track  the 
configuration  as  well  as  to  control  the  fly-fix-fly  tendency,  and  with 
adequate  simulation  for  the  initial  and  follow-on  design  efforts. 


7.2.2. 3  Watch  Items  List 

In  the  F-16  test  cemmunity,  all  of  these  measures  have  been  instituted 
in  varying  degrees  in  the  extensive  F-16C/D  software  development  program. 
The  change  candidates  ocme  frem  a  carefully  mcnitored  "watch  itons"  (WITS) 
list.  To  date  we  have  generated  over  600  different  watch  items,  many  of 
vhich  have  gone  through  the  cycles  and  are  new  closed.  The  vehicle  for 
turning  worthy  watch  items  into  change  candidates,  for  documenting  and 
controlling  configuration  changes,  and  for  judicious  incorporation  of 
updates  is  a  formalized  process  vhich  is  inplemented  through  structured 
weekly  conference  calls  between  the  combined  test  force,  the  contractor(s) , 
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and  the  systems  program  office  (SPO).  During  the  weekly  conference  calls, 
the  discussion  focues  on  new  WITS,  ongoing  contractor  efforts  fron  the 
previous  weeks,  and  SPO  iirplementation  directives.  This  method  has  provided 
continuous  tracking  of  all  the  change  candidates,  allowed  visibility  into 
the  actual  correctve  efforts,  placed  proper  focus  and  enphasis  on  the  higher 
priority  items,  accurate  tracking  and  control  of  configuration,  and 
reasonable  control  of  the  fly-fix- fly  tendency. 


7 . 3  Conclusion 

A  significant  tribute  to  the  developmental  feedback  effectiveness  of 
the  F-16  software  testing  syston  was  a  coclqjit  remechanization  vhich 
included  not  cnly  software,  but  also  hardware  changes.  The  original 
software  architecture  scraetimes  required  up  to  nine  switch  actuations  to 
access  sane  unforeseen,  but  as  it  turns  out  routinely  required  display  and 
data  formats.  With  mission  requirements  more  clearly  defined  through  flight 
test,  and  with  redesign  aided  by  simulation,  a  remechanization  vAiich  reduced 
switch  actuations  for  all  data/display  access  to  a  maximum  of  two  was 
inplemented.  This,  in  essence,  became  the  major  feature  of  Block  25B. 
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Chapter  7 


INTEGRATIOST  FACILITY  FOR  AVIC»JIC  SYSTEMS  TESTING 

"IFAST" 


7.0  Abstract. 

This  paper  describes  the  Integration  Ecicility  for  Avionic  Systems 
Testing  (IFAST)  v^icih  is  being  developed  on  Edwards  Air  Force  Base, 
California,  to  support  avionics  flight  testing  at  the  Air  Force  Flight  Itest 
Center  (AFETC) .  New  avionics  conplexity  has  made  effective  avionics  flight 
testing  difficult,  but  success  will  continue  at  the  AFETC  with  support  frcm 
the  IFAST.  IFAST  provides  a  uniquely  configured  and  sited  building  with 
test  bays  and  automated  systems.  Cotnton  elenents  in  test  facilities  and 
avionics  standards  m^e  the  IFAST  approach  of  multi-user  support  technically 
and  economically  attractive.  Air  Force-contractor  teams  can  apply 
"test-before-fly"  techniques  in  IFAST  vhidh  iitprove  the  in-flight 
utilization  of  test  aircraft.  High  pay-offs  can  come  from  IFAST  si:pport 
applications  like  functional  verification  and  familiarization,  integrated 
troubleshooting,  and  resolution  of  relative  performance  issues  vhich  may 
arise  v>hen  avionics  nodificaticais  are  itade  between  flights.  Past  attempts 
to  "fly  quality  into  avionics"  were  very  time  consuming  and  expensive. 


by  James  M.  Uiderwood,  Jr.,  IFAST  Program  Manager;  Robert  W.  Bockstahler  and 
Dennis  H.  Sheldon,  VE!RAC,  Inc. 
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7 . 1  Introduction 


Since  the  IFAST  is  a  major  support  facility  for  the  AFFTC,  an 
introducticxi  to  the  IFAST  should  include  seme  discussion  of  the  applicable 
portions  of  the  AFETC's  missions.  The  AFFTC  is  responsible  to  Air  Force 
Systems  Cortmand  for  planning,  conducting,  and  independently  reporting  on 
contractor/United  States  Air  Force  (USAF)  development  test  and  evaluation 
(DTScE)  programs  involving  manned  and  unmanned  aerospace  vehicles  and 
deceleration  devices.  Technical  areas  of  responsiblity  include: 

(1)  Performance  and  flying  qualities. 

(2)  Structures,  flutter,  and  climatic  effects. 

(3)  Human  factors  and  operational  utility. 

(4)  Reliability,  maintainability,  and  initial  supportability. 

(5)  Carpatibility  of  support  and  airborne  equipment. 

(6)  Functional  capability/ oonpatibility  of  subsystems. 

As  a  result  of  avionics  proliferation  in  these  aerospace  vehicles 
and  the  increasing  anount  of  software  control  over  the  avionics,  more 
atphasis  is  required  at  the  AFFTC  in  this  last  technical  eirea  on  avionic 
subsystems.  Furthermore,  increasing  costs  and  major  changes  in  avionics 
technologies/applications  made  it  prudent  to  develop  the  IFAST  to  insure 
that  avionics  DT&E  at  the  AFFTC  centinues  to  be  effective  by  producing  the 
best  avionics  possible  and  reducing  costs.  Ihe  success  of  the  IFAST  in 
achieving  these  two  primary  goals  is  practically  guaranteed  1^  general 
agreement  that: 

(1)  Engineering  simulations  have  matured  sufficiently  to  be  used  in 
lieu  of  actual  flight  testing  in  many  iirportant  applications. 
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(2) ,  Highly  beneficial  avionics  groimd  testing  can  be  doie  for 
one-hundredth  the  cost  of  flight  testing  (Ref.  1) . 

(3)  Avionics  ground  testing  in  well  equipped  facilities  can  provide 
substantial  benefits  that  real  flying  cannot  (i.e.,  fireeze,  roll-back,  and 
precise  repeatability) . 

The  lEAST  development  "got  off  the  ground"  in  November  1982  vhen  the 
building  (Fig.  1)  construction  was  ccnpleted.  There  are  other  primary 
efforts  in  the  IFAST  development  vhich  include  the  instcillation  and 
demonstration  of  automated  data  processing  systans  (ADPS)  and  the  phased 
adaptation  of  the  basic  capabilities  to  user  programs.  These  development 
efforts  are  managed  by  the  AFETC's  6520th  Test  Group,  but  operations  within 
individual  IFAST  program  areas  are  managed  by  6510th  Test  Wing  combined  test 
forces  (CTFs)  that  are  manned  by  program  contractor  and  USAF  personnel. 


Figure  1.  IFAST  Building 


Successful  full-scale  development  (FSD)  flight  test  programs  involving 
cctiplex  avionics  must  have  troubleshooting  facilities  like  the  IFAST  at  the 
flight  test  site.  Any  attenpt  to  provide  priitary  srpport.  from  off-site 
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facilities  vd.ll  introduce  delays  and  nonumental  ccmnunications  problems  that 
will  result  is  wasted  time/mon^  and  inappropriate  use  of  FSD  aircraft  to 
troubleshoot  problems  that  could  be  resolved  in  ground  test.  These  cn-site 
facilities  are  not  intended  to  replace  the  developnent/ integration 
laboratories  needed  at  contractor  plants.  A  full  flown  avionics  program 
like  the  F-15  or  B-IB  would  keep  both  facilities  very  busy  vd.th  different 
tasks. 


7.2  Technology  IDipacts 

Rapid  Changes  in  avionics  technology  are  forcing  developnent  of  new 
test  policies,  nethodologies ,  and  resources.  Hrportant  flight  test  elements 
like  techniques,  instrumentation,  and  data  requirements  have  been  impacted 
significantly.  Consideration  of  the  following  functional  changes  provides 
better  insight  into  these  iitpacts: 

(1)  Digital  integration  of  systatis  with  distributed  processing. 

(2)  Extensive  capabilities  under  prograitmable  software  control. 

(3)  New  applications. 


7.2.1  Digital  Integration 

Utilization  of  the  one  megabit  (MIL-STD-1553)  and  higher  speed  digital 
data  buses  in  avicaiics  systems  has  a  very  direct  iitpact  on  flight  testing. 
The  older  generation  of  frequency  and  pulse  code  modulation  instrumentation 
systems,  typically  used  to  acquire  avionics  data  in  flight,  cannot  be  used 
to  acquire  the  large  volume  of  data  frcm  these  high-speed  buses.  As  a 
result,  each  avionics  integration  contractor  develops  a  inique  digital  bus 
instrumentation  and  data  reduction  system  with  little  regcurd  for  inter¬ 
program  ccrnnonality/conpatibility.  These  systons  are  not  csnly  very 
expensive,  but  vary  widely  with  respect  to  performance  characteristics  like 
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time  correlation  accuracy,  data  conpression/alteration  algorithms,  etc. 

They  may  also  be  one-of-a-kind  systems  that  are  integrated  with  other 
contractor  cwned  facilities  and,  if  so,  cannot  be  moved  to  the  AFETC.  Ihe 
AFPTC  is  working  with  industry  and  other  government  flight  test 
organizations  to  acihieve  some  standardization  in  airborne  digital  bus 
instrumentation  and  this  effort  is  a  consideration  in  the  IFAST  development. 


7.2.2  Distributed  Processing 

Trends  toward  more  distribution  of  avionics  data  processing  to 
increasing  numbers  of  embedded  prcoessors  is  reducing  the  availability  of 
data  from  the  digital  integration  buses.  The  end  result  of  this  technology 
impact  is  that  significant  amounts  of  data  needed  for  DT&E  will  only  be 
accessible  fircm  these  processors  through  the  ground  maintenance  connectors 
or  corputer  monitor  and  control  ports  (CMCPs) .  The  CMCPs  also  have 
different  electrical,  mechanical,  and  data  format  characteristics  frcm  one 
manufacturer  to  another  and,  quite  often  frcm  caie  machine  to  another. 

Hence,  another  opportunity  for  cost  effective  cxarnonality/ccttpatibility. 
This  goal  is  also  being  pursued  in  the  IFAST  development  and  is  under 
consideration  by  the  USAF  Deputy  for  Avionics  Control  for  potential 
standardization  in  seme  manner. 


7.2.3  Prograrrmable  Software 

The  capability  to  change  functions/performance  of  avionics  virtually 
overnight  by  reprograitming  software  places  a  substantial  burden  on  DTStE 
personnel.  Timely  assessments  of  the  effects  software  changes  may  have  cn 
functions  that  have  already  been  evaluated  in-flight  are  very  difficult,  if 
not  inpossible,  to  achieve  without  automated  sipport  bools  and  simulation 
data  vhich  can  be  used  for  relative  cenparisons.  Another  very  significant 
inpact  to  flight  test  cemes  frcm  the  increasingly  large  number  of  software 
problens  that  can  be  expected  to  occur  during  FSD  flight  testing  as  a  direct 
result  of  the  correspondingly  large  increase  in  the  amount  of  prograitmable 
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software.  Reasonable  predictions  can  be  made  of  the  number  of  software 
problems  that  would  require  extra  flights  if  no  IFAST  type  facility  were 
available  and  it  might  be  beneficial  to  make  caie  that  ^ows  the  significance 
of  this  technology  iirpact.  For  an  avionics  system  with  640K  words  of 
programmable  software,  a  trial  estimate  indicated  that  major  software 
problems/changes  would  require  120  flights.  This  prediction  covered  the 
canplete  flight  test  period  frcm  pre-baseline  development  through 
post-baseline  evaluation  and  it  only  addressed  software  problems.  A 
conservation  cost  for  these  FSD  flights  exceeds  five-million  dollars. 


7.2.4  New  i^plicaticxis 

More  advanced  weapon  systems  are  ccming  to  the  AFFTC  that  incorporate 
new  avionics  technologies  like  multi-function  displays,  voice  control, 
integrated  fire  and  flight  control,  global  positioning,  sensor  data  fusion, 
etc.  New  innovative  DT&E  techniques  and  support  resources  will  be  needed  to 
insure  the  success  of  these  programs.  These  new  applications  will  irrpact 
the  methodology  arployed  in  flight  testing  activities  like; 

( 1 )  Test  planning . 

(2)  Data  acquisition. 

( 3 )  Problem  resolutions . 

(4)  Data  managenent,  analysis  and  reporting. 

They  will  also  have  a  very  significant  impact  cn  facilities  like  the 
IFAST  frcm  the  standpoint  that  moderate  IFAST  development  will  be  needed 
continuously  to  keep  the  ADPS  and  avionics  interfaces  i:p-to-date. 
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7 . 3  Building  Description 


The  IFAST  building  is  a  three-story,  52,000  square-foot  structure  that 
is  located  southwest  of  Base  Operations.  The  second  and  third  floors  are 
each  configured  to  provide  two  identical,  user  program  areas.  The  IFAST 
cadre  cn  the  first  floor  can  provide  general  support  to  any  of  the  four 
program  areas  or  any  of  the  four  can  be  utilized  in  a  self-contained 
fashicn.  The  first  floor  contains  roans  for  work  breaks, 
conferences/training,  engineering  analysis,  etc.,  for  all  building 
occupants.  Each  user  area  on  the  upper  floors  has  a  shielded  bay  v»hich  can 
be  opened  for  emitters  to  scan  targets  outside  the  building.  The 
half-sphere  danes,  shown  in  Figure  1  at  each  end  of  the  top  flcxar,  were 
installed  for  this  purpose.  The  building  site  and  orientation  were  chosen 
to  provide  each  bay  with  an  unobstructed  view  of  targets  of  opportunity  in 
the  normal  aircraft  traffic  patterns.  This  design  feature  greatly  reduces 
the  number  of  dedicated  target  missions  that  would  have  to  be  flown 
otherwise.  Other  general  features  of  the  building  include: 

(1)  Automated  security  with  card-key  access  control. 

(2)  Large  freight  elevator  to  all  floors  and  rcof. 

(3)  Heavy  load  bearing  roof  with  anchor  fittings  for  large  antennas. 

(4)  Integrated  cxximunications  within  the  building,  on  base,  and  with 
ARPANET. 


Other  features  of  each  user  area  are: 

(1)  Avionics  utilities. 

(2)  Raised  technical  flooring. 

(3)  Engineering/ administrative  space. 
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(4)  Shop  and  storage  areas. 

(5)  Halon  fire  protection. 


7.4  Autonated  Data  Processing  Systans 

Development  of  the  IFAST  ADPS  is  being  done  vdth  a  phased  approach 
under  direct  government  racinageraent.  Lessons  learned  from  each  phase  are  fed 
back  into  the  requirements  of  each  succeeding  phase.  The  following  list  of 
phases  provides  an  oveirview  for  development  of  a  time— shared  cortputer 
ccnplex  and  the  initial  test  bay  carputer  catplex. 

(1)  Installation  and  checkout  of  basic  systems. 

(2)  Rehost  of  government  owned  simulation  si:pport  software. 

(3)  Developnent  of  coclqsit  operator  station  (COS). 

(4)  Real-time  simulation  demonstration  with  real  avionics. 

(5)  Initial  user  program  adaptation. 

(6)  Development/ installation  of  avionics  software  tools. 

(7)  Development  of  generic  simulation  software. 

(8)  Development  of  generic  performance  monitoring  and  control  systems. 

(9)  Adaptation  to  other  user  programs. 
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7.4.1  Time-shared  Conputer  Gcnplex 


This  cdtplex  is  located  cn  the  first  floor  to  support  real-time 
simulation  software  developnent,  test  scenario  generation,  avionics  software 
development/modifications,  data  base  management,  and  remote  comnunications . 
It  provides  interactive  terminals,  mcxiems,  inter-ccnputer  networks,  and  the 
following  systems; 

(1)  A  Digital  Equipment  Corporation  (DEC)  2060  mainframe,  general 
purpose  ccttputer  system  with  twD  megawords  of  memory;  2400  megabytes  (MB)  of 
disc  storage;  800/1600  and  6250/1600  bits-per— inch  (bpi)  selectable  density 
tape  drives;  a  900  lines-per-minute  (Ipra)  scientific  character  printer;  a 
letter  quality  printer;  and  remote  device  interfaces. 

(2)  A  DEC  VKK.  11/782  simulaticai  development  miniccnputer  system  with 
two  central  processor  units  and  3  3/4  MB  of  memory;  768  MB  of  disc  storage; 
6250/1600  bpi  selectable  density  tape  drives;  a  600  1pm  printer/plotter;  and 
a  16-color  raster  graphics  systam. 

(3)  A  EEC  VAX  11/750  graphics  development  miniccnputer  system  with  2 
MB  of  memory;  335  MB  of  disc  storage;  a  1600  Ipi  tape  unit;  hcirdoopy 
terminal;  Evans  and  Sutherland  (E&S)  color  picture  system;  Alage  graphics 
system;  and  Versatec  22  inch  plotter. 


7.4.2  Test  Bay  Ooirputer  Ccnplex 

Initially  only  cxie  of  these  four  test  bay  ccnplexes  will  be  developed 
by  the  IFAST  program  and  applied  to  a  DT&E  program.  The  other  three  bays 
will  be  populated  by  air  vehicle  prime  ocaitractors  or  avionics 
subcontractors  until  more  AFPTC  expertise  is  gained  and  applied  to 
additional  DT&E  programs  with  appropriate  scheduling.  This  ccnplex 
interfaces  with  the  real  avionics  through  the  MIIr-STD-1553  digital  data  bus 
and  standard  synchro,  analog,  and  discrete  signals.  The  primary  systems 
included  in  this  initial  ccnplex  include; 


83 


(1)  Two  DEC  VAX  11/780  real-time  simulation  minicxsrputer  systons  with 
2  MB  of  memory  each  and  3  MB  of  shared  memory  that  can  be  connected  to  two 
more  ll/780s;  6520/1600  bpi  selectable  density  tape  drives;  a  600  Ipm 
printer/plotter;  and  a  16— color  raster  graphics  system. 

(2)  A  DEC  VAX  11/750  minicorputer  system  for  real-time  control  of  an 
E6cS  graphics  system,  with  2  MB  of  memory;  335  MB  of  disc  storage;  E&S  color 
picture  system;  Adage  graphics  system;  and  Versatec  22  inch  plotter. 

(3)  A  EEC  VAX  11/730  simulation  data  monitoring  and  control  mini- 
ccrputer  syston  with  1  MB  of  memory;  30  MB  of  disc  storage;  and  avionic 
systems  interfaces. 


7.5  Test  Bay  #1  Initial  Implementation 

The  initial  test  bay  complex  implonentationn  will  combine  the  computer 
systems  described  above  with  an  in-house  developed  generic  Cocl<pit  Operator 
Station  (COS)  to  provide  a  real-time  flight  simulation  demonstration  and 
avionics  test  platform.  A  block  diagram  of  the  COS  and  its  ccamections  with 
the  test  bay  computer  system  and  support  equipment  is  shown  in  Figure  2. 


7.5.1  Cocl^it  Operator  Station 

The  heart  of  the  IFAST  real-time  avionics  system  development  is  the  COS 
vhich  consists  of  a  cockpit  itvcckup  vhich  contains  data  acquisition  and 
control  syston  and  F— 16  avionics  ccnponents  that  were  selected  for  an 
initial  simulation  deitonstration.  The  avionics  functicxis  incorporated  in 
the  COS  include: 

(1)  F-16A  Fire  Control  Conputer  (FCC) 

(2)  Fire  Control/Navigation  Panel  (FC/NP) 
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(3) 


Head  llt>  Display  (HUD) 


(4)  Actual  and  simulated  flight  instruments 


(5)  Sidestick  cpntroller,  throttle,  and  rudder  pedals 


Kl-ll  1  KCMCT 


Figure  2. 


Test  Bay  #1  Initial  Configuration 
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(6)  Simulation  Control  Panel 


(7)  Simulated  Multi-Function  Display 

Electrical  interfaces  with  the  cockpit  are  handled  by  the  ISI-ll/23 
based  Data  Ttoquisition  Ocitputer  System  (DACS) .  The  DACS  incorporates 
digital,  analog,  synchro,  and  discrete  signal  conditioning  for  cockpit 
ocnponents.  Generic  growth  capability  is  designed  into  the  system  via  a 
modular  chassis  concept  and  plug-in  interface  circuit  cards. 

The  DACS  software  controls  cockpit  interface  functions  and  is  adaptable 
to  most  hardware  conf igxarations .  In  the  initial  inplementation,  the 
software  performs; 

(1)  Systan  readiness  testing 

(2)  Instrument  and  control  calibrations 

(3)  Instrument  data  conversion  and  scaling 

(4)  Simulation  control  and  operator  input  recognition 

(5)  Data  formatting/camiunicatian  with  VAX  simulation  system 


7.5.2  Interprocessor  Link 

The  interprocessor  link  provides  a  high  speed  parallel  data  path 
between  the  simulation  system  and  the  DACS.  Utilizir^  a  cantDn  memory 
interface,  this  link  supports  software  download,  bidirectional  simulation 
data  transfer,  and  sync  interrupts  from  the  VAX  11/780  to  the  ISI-ll/23. 
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7.5.3  Simulation  Subsystem 


Ihe  dual  V7\X  11/780  ccnpjters  host  the  aircraft  aerodynaitdc  and  basic 
avionic  system  simulation  models.  The  avicnics  model  packages  incliide  the 
Inertial  Navigation  System,  Instrument  Landing  System,  Stores  Management 
System,  HUD,  and  weapons  operation  and  scoring.  A  prograitmable  multiplex 
bus  terminal  connects  the  simualtion  ocnputers  to  the  1553B  Mux  Bus  arployed 
by  the  POC  and  FC/NP.  Ey  responding  on  the  bus  in  real  time  vdth  simulated 
avionics  data,  the  simulation  stibsytem  can  provide  realistic  flight 
performance  dynamics  vAiich  are  repeatable  and  easily  instrumented. 


7.5.4  Graphics  Subsystem 

The  graphics  ccnputer  system  receives  simulated  aircraft  and  target 
flight  data  and  HUD  display  information  formthe  simulation  subsystem  vhich 
it  uses  to  drive  a  display  situated  in  front  of  the  coclqjit.  This  display 
provides  out-the-windcw  scenery  graphics  with  a  sr^jerinposed  HUD  display  (if 
selected)  for  flight  orientaticxi  and  landmark  recognition. 


7.5.5  Performance  Monitoring  Subsystem 

In  addition  to  the  VAX  11/730  ccnputer,  the  p)erformance  monitoring 
siibsystem  (PMS)  includes  a  progranmable  multiplex  bus  terminal  configured  to 
monitor  data  activity  on  the  15538  Mux  Bus.  Bus  traffic  nay  be  selectively 
displayed  and  recorded  for  later  reduction  and  analysis. 

The  also  includes  a  high  speed  ccxitroller  (HSC)  that  is  connected 
to  the  maintenance  pxsrt  of  the  POC.  This  device  permits  control  and 
breaJqxoint  monitoring  of  the  POC  during  real  time  simulation  to  generate 
sync  interrupts  to  the  simulation  siibsystem  software.  The  HSC  is  also  used 
to  download  an  operationcil  flight  program  (OPP)  into  the  POC. 
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7.6  Utilization 


The  priitiary  purpose  of  the  IFAST  is  to  support  avionics  flight  testing. 
As  such,  the  first  order  of  business  is  assessment  of  avionics  flight 
readiness.  If  problems  occur  before  or  during  a  flight,  the  second  order  of 
business  is  a  quick  assessment  to  determine  vhat  subsequent  actions  are 
appropriate.  This  test-before-fly  process  uses  real-time  simulation  in 
IFAST  to  provide  an  integrated  checkout  of  the  avionics.  In  order  to  insure 
the  validity  of  assessments,  the  avionics  configurations  and  simulations 
must  be  reascnably  accurate,  an!  if  so,  dynamic  evaluaticxi  of  the  avionics 
in  simulated  flight  conditions  can  be  done  through  the  use  of  sophisticated 
performance  nmitoring  and  control  in  IFAST. 

The  capability  for  testing  the  avionics  prior  to  flight  results  in 
several  hi^  payoff  areas.  A  few  of  the  more  in^aortant  areas  are: 

(1)  Safety  of  flight  validation 

(2)  Crew  familiarizaticn  and  smart  test  planning 

(3)  Acquisition  of  test  data  for  simulation  baseline  performance 

(4)  Reduction  of  system  integration  time. 

The  role  of  the  IFAST  in  these  important  areas  is  to  provide  a  major 
benefit  to  test  programs  by  allowing  the  expensive  flight  test  hours  to  be 
used  for  gathering  meaningful  data  to  evaluate  weapon  systems  performance. 
Through  the  use  of  the  real-time  simulation  capability,  users  can  evaluate 
the  performance  of  each  subsystem  in  a  system  context  and  can  better 
understand  the  complex  interacticxis  of  the  subsystems. 

The  value  of  using  a  flight  test  support  facility  like  the  IFAST  must 
be  measured  in  oonsideraticxi  of  the  efficiency  and  oonpleteness  it  offers  as 
a  supplement  to  flight  testing,  as  well  as  the  relatively  minimal  cost  of 
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operating  it.  However,  the  high  payoff  cones  fron  the  increases  in  quality 
of  the  products  placed  in  operaticaial  service. 


7.7  References 


1.  "New  Analytical  Tools,"  Aviatloi  Week  &  Space  Technology,  January  17, 
1983. 


89 


